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WELCOME 


The  National  Computer  Security  Center  and  the  Institute  for  Computer 
Sciences  and  Technology  are  pleased  to  welcome  you  to  the  Eleventh  Annual 
National  Computer  Security  Conference.  The  past  ten  conferences  have 
stimulated  the  sharing  of  information  and  the  application  of  this  new 
technology.  We  are  confident  the  Eleventh  NCS  Conference  will  continue  this 
tradition. 

This  year's  conference  theme— Computer  Security:  Into  the  Future- 
re  fleets  the  growth  of  computer  security  awareness  and  a  maturation  of  the 
technology.  Our  next  major  challenge  is  to  understand  how  to  build  secure 
applications  on  trusted  bases.  The  efforts  of  the  National  Computer  Security 
Center. the  Institute  for  Computer  Sciences  and  Technology,  computer  users,  and 
the  computer  industry  have  all  contributed  to  the  advances  in  computer  security 
over  the  past  few  years.  We  are  committed  to  a  vibrant  partnership  between  the 
Federal  Government  and  private  industry  to  further  the  state  of  the  art  in 
computer  security. 

Our  challenge  is  to  build  upon  the  foundations  we  have  established  so  that 
secure  applications  emerge.  We  must  understand  and  record  how  we  build  on 


these  foundations  in  order  to  secure  user-based  systems.  To  be  successful,  we 
need  your  . ielp  as  you  take  back  to  your  places  of  work  an  increased  awareness 
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Abstract  •  This  paper  describes  a  security  model  for  a  Multilevel  Secure 
Object-Oriented  System.  The  model  is  posed  in  terms  of  an  object-oriented 
computation  model  incorporating  distributed  co-operating  objects.  The  model 
supports  n  data  sensitivity  level  classification  appropriate  for  use  in  Multilevel 
Secure  Database  Management  Systems  (MLS/DBMS).  This  security  model 
allows  a  subject  to  act  with  the  lowest  clearance  level  necessary  to  accomplish 
a  task  and  thus  avoid  over-classification  of  data.  The  paper  discusses  the 
security  properties  of  the  model,  including  the  safety  of  message  passing  and 
die  existence  of  covert  channels. 

Index  Terms  -  Multilevel  Security,  Multilevel  Secure  Database 
Management  Systems.  Security  Model,  Object-Oriented  Systems 

1.  Introduction 

MultiLcvcl  Secure  Database.  Management  Systems  (MLS/DBMSs)  allow 
users  with  dilTercnt  clearance  levels  to  shine  a  database  consisting  of  data 
having  varying  sensitivity  levels.  MLS/DBMSs  uchicvcd  prominence  tit  the 
Air  Force  Summer  Study  of  1982  [AIRF82]  us  a  method  of  preventing  DBMS 
security  violations.  During  ‘he  study  various  designs  for  MLS/DRMSs  were 
proposed,  One  design  bxset.  on  a  near-term  set  of  requirements  incoiporolcd 
off-the-shelf  concepts  in  its  solution  and  another  based  on  a  long-term  set  of 
requirements  including  content,  context  and  dynamic  classification  ami  a 
solution  to  the  inference  and  aggregation  problem.  The  committee  members 
defined  a  partial  solution  and  outlined  further  research. 

Rcccndy  much  reseated  is  devoted  to  the  design  of  Multilevel  Secure  Rela¬ 
tional  DBMS  |DENN87b,  DILL86,  DWYE87|.  Techniques  to  deal  with  the 
inference  and  aggregation  problems  are  also  t-.-ing  investigated  IHINKH8, 
MORG88,  SUOZ87,  THUR87,  THUR88), 

The  relational  data  model  is  well  defined  and  generally  applicable  to  a  wide 
range  of  data  modelling  problems.  For  some  problem  domains  involving 
Multimedia  DBMS  and  CAD/CAM,  object-oriented  systems  present  a  more 
suitable  data  model  and  have  become  |x>pulur  for  use  in  these  domuins. 

Object-oriented  systems  began  as  programming  systems  and  are  only  now 
dealing  with  issues  such  us  data  models,  predicate  based  queries  (CHEN87I, 
schema  evolution,  version  cuntrol  |BANE87|,  transactions  and  cnnirollcd 
sharing  of  data  |FISH87|.  Resolving  these  issues  paves  the  way  for  more 
useful  object-oriented  DBMS  and  generates  a  need  for  security. 

Object-oriented  DBMSs  unify  u  data  model  and  a  computational  model  setting 
them  apart  from  relational  systems.  The  relational  algebra  docs  nol  deal  with 
tlte  subject  of  updating  or  creating  new  relations  even  though  most  relational 
DBMS  do  provide  this  capability.  Tile  fact  that  the  object-oriented 
computational  model  allows  for  creation  and  modification  of  data  as  well  us 
data  access  forces  a  security  model  to  dcul  with  the  problem  of  darn 
moth  ficat  ion. 

The  computational  model  also  defines  objects  as  isolated  computational 
entities  communicating  explicitly  with  other  objects  through  messages.  This 
naturally  leads  to  distributed  security  enforcement  rather  than  the  centralized 
enforcement  possible  with  relational  queries. 

Previous  work  on  security  in  object-oriented  systems  has  been  done  to  enforce 
discretionary  and  mandatory  security  policies.  (ANCI83I  describes  a  protection 
mechanism  and  defines  how  it  may  be  embedded  in  an  object-oriented 
concurrent  programming  language.  The  protection  mechanism  is  based  on 
capabilities  and  allows  for  static  access  control.  The  protection  mechanism 
implements  discretionary  but  dues  not  address  mandatory  security. 

Mandatory  security  is  investigated  in  (MIZU87),  Security  is  enforced  widi  a 
combination  of  compiic-iime  and  run-time  cheeks.  The  security  model 
classifies  variables  us  having  a  fixed  or  indeterminate  sensitivity  level.  The 
indeterminate  levels  are  meant  to  dcul  with  indeterminate  inlormalion  flows 


and  must  be  checked  at  run-time.  The  security  model  docs  not  support  the 
classification  of  dntu  according  to  its  content  and  does  not  support  a  separate 
classification  for  aggregate  data  objects. 

When  classifying  data  in  a  database  two  factors  arc  considered,  the  type  of  darn 
that  has  been  created  and  the  sensitivity  level  of  the  data  which  is  used  to 
create  it.  Security  constraints  atlempt  to  model  the  correlation  between  types 
of  data  and  corrcs|>onding  sensitivity  levels.  In  many  systems  the  subject's 
security  clearance  level  is  assumed  to  be  the  sensitivity  level  of  data  used  in 
creating  a  new  datum.  This  is  based  on  the  fact  that  the  subject's  clearance 
level  represents  the  most  sensitive  datum  the  subject  has  uccess  to.  This  leads 
to  over-classification,  since  this  clcuruncc  level  will  always  dominate  the 
actual  sensitivity  level  of  data  incorporated  in  the  result.  [WOOD87]  discusses 
the  classification  of  information  based  on  its  composition.  Data  is  marked 
with  sensitivity  labels  which  truck  the  least  upper  bound  of  all  data  in  the 
composite  object.  A  covert  channel  is  identified  which  exists  when  u  higher 
clearance  subject  causes  an  object  to  become  unreadable  by  a  subject  with  a 
lower  clearance.  To  avoid  this  channel,  the  labels  are  used  in  an  advisory 
manner  and  not  in  the  enforcement  of  mandatory  security.  Separate  Mandatory 
Access  Control  Levels  (MACLs)  uro  attached  to  data  objects  for  this  purpose. 
This  upproaeli  docs  not  solve  the  over-dassificulion  problem  with  respect  to 
mandatory  uccess,  since  the  MACLs  do  not  represent  the  highest  sensitivity 
level  of  data  known  by  the  process  which  created  the  object  but  tlte  highest 
sensitivity  level  of  datu  die  subject  is  allowed  to  know.  The  model  described 
in  IWOOD87]  assumes  that  the  sensitivity  level  of  an  object  is  independent  of 
other  objects’  values  and  sensitivity  levels.  This  ussumption  is  not  consistcnl 
with  requirements  Tor  security  in  DBMSs. 

We  propose  a  security  model  for  a  Multilevel  Secure  Object-Oriented  System 
with  the  following  advantages.  It  is  posed  in  Icons  of  an  object-oriented 
computation  model  incorporating  distributed  co-operating  objects.  Each  object 
is  assumed  to  be  a  scir-conlaincd  computing  element  whose  only  interaction 
with  other  objects  Is  through  sending  ami  receiving  messages.  The  model 
supports  a  mandatory  security  policy  with  extensions  to  support  tlte  data 
classification  necessary  for  use  in  MLS/DBMS.  This  security  model  allows  a 
subject  to  act  with  the  lowest  security  classification  level  necessary  to 
accomplish  a  task  und  thus  avoids  over-classification  of  data  in  the  presence  of 
updates.  The  model  docs  this  without  introducing  the  covert  channel  as 
discussed  in  [WOOD87J,  This  allows  data  classification  to  follow  a  set  or 
security  constraints  defined  on  the  database  schema  und  not  the  security 
clearance  level  of  users  making  the  updates. 

The  organization  of  this  paper  is  us  follows:  Section  2  describes  the  essential 
points  of  MLS7DBMS.  Section  3  gives  an  overview  of  object-oriented 
systems.  Section  4  describes  a  multilevel  security  model  Tor  object-oriented 
systems  and  Section  5  discusses  the  security  properties  of  the  model.  Finully, 
Section  6  concludes  this  paper  with  future  considerations. 

2.  MLS/DBMS 

A  MLS/DBMS  is  different  from  a  conventional  DBMS  in  at  least  the 
following  ways: 

1 .  Every  data  item  in  die  database  has  associated  with  it  one  af  several 
classifications  or  sensitivities,  that  may  need  to  change 
dynamically  over  time, 

2.  A  user's  access  to  dalu  must  be  controlled  based  upon  the  user’s 
authorization  with  respect  to  these  data  classifications. 

Providing  n  Ml.S/DBMS  on  current  computing  systems  presents  many 
problems.  The  granularity  of  classification  in  a  DBMS  is  generally  finer  than 
a  file  und  may  be  as  fine  as  a  single  data  element.  Another  problem  that  is 
unique  to  databases  is  the  necessity  to  classify  data  based  on  content,  lime, 
agpegation  and  context.  DBMSs  are  also  vulnerable  to  inference  attacks  where 
a  user  infers  unauthorized  information  from  legally  obtained  data. 
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A  solution  proposed  to  overcome  some  of  these  problems  in  relational 
database  management  systems  is  to  ure  security  constraints  to  associate 
classification  levels  with  all  dala  in  a  database  [DENN87a,  DWYE87],  The 
constraints  provide  the  basis  for  a  versatile  and  powerful  classification  policy 
because  any  subset  of  data  can  be  specified  and  assigned  a  level. 

Simple  constraints  provide  for  the  classification  of  the  entire  database,  as 
well  as  the  classification  by  relation  and  by  attribute.  Constraints  that 
classify  by  content  provide  the  mechanism  for  classification  by  tuple  and  by 
element.  Context-based  constraints  classify  relationships  among  dala.  In 
addition,  the  results  of  applying  a  function  to  on  attribute  in  all  or  a  subset  of 
tuples  in  a  relation,  such  as  sum,  average,  and  count  can  be  assigned  different 
classification  levels  than  the  underlying  data.  Finally,  the  classification  levels 
of  the  data  can  change  dynamically  based  upon  changes  in  time,  content,  or 
context. 

A  constraint  consists  of  a  data  specification  and  a  classification.  The  data 
specification  defines  any  subset  of  the  database  using  relational  algebra  and  the 
classification  defines  the  classification  level  of  this  susset.  For  example, 
consider  a  database  which  consists  of  a  relation  EMP(NAME.  SALARY, 
SOC.SEC#)  with  SOCJSF.C#  as  the  key.1 

The  content-based  constraint,  using  ihe  notation  proposed  in  [DWYE87], 
w  hich  classifies  the  names  of  all  employees  who  cam  more  than  50K  as 
Secret  is  expressed  as: 

LEVEL(PROJECT[NAMEl  (SELECTS  ALARY>50K  I  EMP)) . 

SECRET 

and  the  context-based  constraint  whicn  classifies  all  names  and  salaries  taken 
together  as  Secret  is  expressed  us: 

LE  VLLfPROJ ECT[NAME,  SALARY]  EMP)  «  SECRET 

The  simple  constraints  which  classifies  ail  names  and  salaries  token 
individually  as  Secret  is  expressed  os: 

LEVEL(PROJECT|NAME]  EMP)  -  SECRET 

LEVEL(PROJECTISALARY)  EMP) »  SECRET 
3.  Object-Oriented  Systems 

This  section  gives  a  brief  background  on  object-oriemed  systems.  There  is  a 
wide  variation  in  what  is  meant  by  "objec'-oricntui".  Most  of  our 
interpretation  comes  from  SMALLTALK-80  (GOLD83|.  Variations  on  this 
object-oriented  model  arc  given  in  (STEF361.  The  object-oriented  model  as 
defined  by  SMALLTALK  was  intended  as  a  programming  system.  Our 
definition  of  an  object-oriented  system  also  stems  from  our  desire  to 
incorporate  database  considerations  such  as  data  models,  predicate  based 
queries,  schema  evolution,  version  control,  transactions  and  controlled  sharing 
of  data.  Out  understanding  of  these  issues  eomes  from  1BANE871,  (FISHH7I 
ami  (YOON871. 

Ill  an  object-oriented  system  everything  is  represented  as  an  object.  An  object 
is  made  up  of  private  stute  information  and  a  set  of  actions  which  rcp".scnl  Uio 
only  way  to  access  or  modify  this  state  information.  The  state  information  is 
represented  as  a  set  of  instance  variables  whose  values  are  objects  each  of 
which  contains  its  own  sure  information  and  methods.  The  actions  defined  on 
an  object  are  called  methods.  A  method  carries  out  its  action  by  sending 
messages.  A  message  consists  of  a  method  selector,  which  is  ihc  name  of  the 
method  to  be  Invoked,  followed  by  a  list  of  objects  to  be  used  as  arguments  to 
the  method.  Sending  a  message  to  an  object  causes  a  method  to  be  executed. 
Objects  art  passive  entities  which  store  information.  A  method  is  also  passive 
and  represents  a  function  which  can  be  performed  on  an  objecl.  A  message 
combined  with  an  object  yields  a  method  activation.  Method  activations  are 
active  and  perform  the  computation  in  the  system. 

Primitive  objects  represent  their  state  directly  without  using  other  objects, 
examples  of  these  primitive  objects  are  numeric  values,  strings  and  identifiers. 
Primiiive  methods  represent  actions  carried  out  directly  by  the  virtual  machine 
without  sending  messages,  examples  are  adding  numeric  values  and  reading  the 
value  of  an  instance  variable, 


[The  notation  used  in  our  discussion  of  database  concepts  and  relational 
algebra  is  based  on  [ULLM82|. 


Each  object  has  a  type  or  class  it  belongs  to,  All  objects  in  a  class  are 
equivalent  computationally,  Each  may  have  a  different  state  but  Ihe  type  of 
computation  which  can  be  performed  on  an  object  is  uniform  throughout  the 
class,  The  class  defines  what  methods  are  available  in  instances  of  the  class 
and  what  instance  variables  are  included  in  the  Instance  objects.  The  class  of 
nn  object  is  also  an  objecl.  A  class  object  responds  to  messages  to  create  new 
instance  objects.  A  class  object  defines  a  type  by  specifying  the  types  which  it 
specialises,  These  types  are  referred  to  as  its  super-types.  An  object  inherits 
methods  and  access  to  instance  variables  from  its  class  object  and  each  super¬ 
type  of  ihe  class  object  all  the  way  up  the  lattice  to  the  root,  OBJECT. 

An  object  represents  a  distributed  computation  element.  Methods  are  specified 
such  that  only  data  contained  in  the  object  receiving  the  message  can  be 
modified  directly.  A  method  activation  has  no  knowledge  about  the  states  of 
other  objects  unless  it  explicitly  queries  them  and  it  can  not  affect  the  stare  of 
other  objects  except  through  requests  to  them.  Each  method  activation 
performs  an  independent  compulation  except  where  it  explicitly  communicates 
by  sending  a  message. 

For  the  most  part,  methods  arc  described  informally  in  the  text.  When  we 
wish  to  be  more  precise  we  will  use  notation  similar  to  that  in  [GOLD83],  A 
method  specification  consists  of  a  message  pattern  and  a  sequence  of 
expressions  separated  by  periods.  The  message  patient  determines  the  message 
selector  the  method  will  be  used  for  and  assigns  names  to  the  formal 
parameters  or  the  method.  An  example  of  a  message  pattern  is  shown  below: 

spend:  amount  on:  reason 

The  message  selector  for  this  method  is  'spcnd:on:',  The  two  formal 
parameters  in  this  method  arc  'amount'  and  'reason'.  Tho  expressions  which 
make  up  the  body  of  the  method  consist  of  messuge  expressions  with  an 
optional  assignment.  Message  statements  are  described  briefly  below: 

Unary  Mermges 

A  unary  message  consists  of  the  name  of  the  receiver  object  followed  by  the 
selector  or  the  method  to  be  executed.  The  statement  below  sends  Iho  message 
consisting  of  a  selector  named  ’salary'  and  no  parameters  to  tho  object 
'EmpOl': 

EuipOl  salary 

Keyword  Messages 

A  mtssuitc  --an  be  constructed  from  parts  of  the  selector  or  keywords  alternated 
with  arguments.  The  following  message  sends  the  object  'HouseHoldFinanccs' 
he  selector  rpcnd:on:  along  with  objects  representing  the  real  number  30.45 
and  the  string  food'. 

HouseHoldFinanccs  spend:  30.45  on:  'food' 

A  message  expression  returns  an  object  us  a  result  whiclt  represents  the  value 
of  the  expr lion.  This  objecl  can  be  assigned  to  an  instance  variable.  This  is 
done  by  )  re-  .-ding  the  message  expression  with  the  name  of  the  variable  and 
the  assignment  symbol  W  as  in  the  example  below: 

TotolFinanccs  a-  TotalFinanccs  +  (HouscHoldFinunccs  lotalSpcmFor: 
'food) 

blocks 

A  block  is  similar  to  a  function  In  a  traditional  programming  language.  It 
lakes  a  list  of  arguments  and  produce;  a  result.  A  block  is  simitar  in  form  to  a 
method.  It  is  enclosed  in  square  brackets  and  begins  with  a  list  of  parameters. 
Separated  from  the  parameters  by  a  T  is  ?  list  of  expressions  which  form  the 
body  of  the  block.  I  he  block  shown  below  Is  a  function  of  one  argument 
'ObjectToClassify'  and  returns  a  boolean  result: 

t:ObjectToClassify  t  (ObjectToClassify  salary)  >  100000  ] 

The  block  sends  its  argument  the  message  'salary'  and  to  the  resulting  object  It 
sends  the  message  with  selector  ’>’  and  argument  100000.  A  block  is  an 
object  and  can  be  used  as  an  argument  to  a  method. 

4,  Security  Model 

This  section  proposes  a  security  model  posed  in  terms  of  the  object-oriented 
computing  model.  The  model  combines  the  use  of  security  constraints  for  data 
classification  with  mandatory  access  control.  Security  constraints  allow  the 
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automatic  classification  of  data  objects  by  their  type  and  by  their  tclation  to 
other  data.  Classification  by  security  constraints  conflicts  with  classification 
by  information  flow  A  newly  created  object  has  two  classifications,  one  by 
an  applicable  security  coast  ruin  l  and  another  from  the  current  security 
classification  of  the  user  creating  die  object,  (a  user  can  only  write  objects 
with  v  u\iiiviiy  levels  dominating  their  current  security  classification  level). 
A  distinguishing  aspect  of  this  model  is  the  emphasis  placed  on  classification 
derived  front  security  constraints. 

|DENNK7c|  uses  security  constraints  to  classify  newly  entered  data.  Once 
classified,  the  MACLs  are  fixed  and  do  not  respond  to  changes  in  related  data. 
Since  the  levels  arc  fixed,  after  some  updates  to  the  database  the  levels 
assigned  to  data  may  not  he  consistent  with  the  levels  assigned  by  the 
constraints.  Consider  Lite  security  constraint  which  classifies,  the  names  of 
employees  as  Secret  when  the  employee's  salary  is  greater  than  $100,000.00 
and  the  name  is  Unclassified  otherwise.  When  an  employee’s  salary  is 
increased  u>  over  $100,000.00  the*  sensitivity  level  of  the  name  remains 
Unclassified  by  this  model.  In  this  model  the  sensitivity  level  of  a -latum  docs 
not  depend  solely  on  the  applicable  security  constraints  and  therefore  there  can 
Iv  more  than  one  sensitivity  level  for  a  datum.  Since  the  key  value  docs  not 
detciminc  the  sensitivity  level  of  an  entity,  [tolyiusluniuttion  |DENKX7b]  is 
used  to  disallow  a  low  level  user  from  overwriting  higher  level  invisible  data 
without  opening  -t  covert  clumnel. 

The  opposite  extreme  is  a  model  which  insures  that  security  constiainls  arc 
always  maintained.  The  levJ  of  each  piece  of  data  is  completely  determined  by 
the  applicable  security  constraints.  This  « odd  allows  only  those 
modifications  m  (he  database  which  maintain  the  security  classification 
determined  by  the  secuiiiy  constraints  and  udnering  to  information  How 
restrictions.  In  the  case  of  the  classification  disctis/ed  above,  if  a  Secret  user 
created  an  employee  with  it  salary  over  $100,1X10.00,  Urn  data  would  be 
inserted  in  the  database.  If  it  were  attempted  by  a  Top  Secret  user  it  would  he 
rejected  since  the  data  would  have  to  be  classified  Top  Secret  to  dominate  the 
clearance  level  of  the  user  which  is  in  conlliet  with  the  level  Secret  assigned 
by  the  security  constraint.  Ir.  this  model,  the  security  level  of  an  object  is 
completely  determined  by  security  constraints.  If  the  security  constraints  are 
conditioned  only  on  the  key  value  of  an  entity,  the  key  value  completely 
determines  the  sensitivity  level  and  po'yinsiuntiaiion  is  unnecessary. 

The  proposed  model  is  somewhere  i*ctween  the  other  two.  it  allows  u  subject 
to  act  with  the  lowest  authority  possible  so  that  data  can  more  often  be 
classified  in  accordance  with  sivunv  constraints.  It  applies  the  security 
eon,.lrnims  in  a  dynamic  fashion  cha  tging  the  classification  of  a  piece  of  data 
when  the  security  constraint  deri  *cd  level  changes.  l?or  example,  if  the  names 
of  employees  arc  classified  Secret  when  lire  employee's  salary  is  greater  than 
$100, 000,00  ami  Unclassified  other  isc,  then  when  an  employee's  salary  is 
increased  to  over  $  100, 000. (X)  the  sensitivity  level  ol  the  name  is  also 
changed.  Tins  model  insures  thm  an  object’s  assigned  sensitivity  level  always 
dominates  the  sensitivity  level  determined  by  security  constraints.  This  model 
must  rely  on  polyinstantiation  since  Mio  sensitivity  level  of  an  object  is  not 
detei  mined  solely  by  security  constraints.  Modifying  the  security  classification 
level  of  subjects  and  objects  dynamically  can  open  covert  storage  channels  uno 
so  need  to  be  done  with  caution.  The  proposed  model  allows  these  level 
changes  in  only  thus ;  cases  whcie  u  covert  diaiincl  can  not  exist. 


Messages  A  message  is  sent  on  behalf  of  a  security  subject.  It  is 

sent  to  an  object  requesting  execution  of  a  selected 
method  with  the  authority  of  the  security  subject  which 
the  message  represents.  A  message  is  an  object  and 
therefore  is  protected  by  the  security  system.  Messages 
arc  labelled  with  two  security  classification  levels.  Tire 
first  is  the  clearance  level,  I-Sclcar.  of  the  security 
subject  originating  die  message.  The  second  level  is  the 
current  security  classification  level,  Lseurrcni,  of  the 
originating  subject.  These  two  levels  act  as  an  upper 
anti  lower  bound  on  the  classification  level  of  the  new 
method  activation. 

Method  Activation  Method  activu'iuns  arc  the  only  active  entities  in  the 
model  and  therefore  represent  security  subjects.  Each 
method  executes  in  a  separate  context  described  by  an 
activation.  The  execution  is  carried  out  by  sending 
messages  to  objects.  Sending  messages  is  not  a  sc  urity 
relevant  action,  for  two  reasons.  First,  because  the 
message  carries  with  it  boundaries  on  the  authority  of 
the  method  activation  it  cremes,  which  arc  encompassed 
by  the  boundaries  of  the  subject  sending  the  message. 
Secondly,  the  data  sent  in  messages  is  in  the  form  or 
protected  objects.  These  points  will  be  discussal  more 
fully  in  die  section  describing  model  properties.  Certain 
primitive  actions  such  as  reading  an  instance  variable, 
wMing  an  distance  variable,  carrying  out  a  conditional 
jvlion  or  ci eating  a  new  object  are  carried  out  directly 
by  the  method  activation  without  sending  any  mes¬ 
sages.  These  actions  are  security  relevant  since  they 
directly  access  and  modify  information  in  the  method 
activation  and  instance  variables  uf  the  object. 

4.2.  Security  Constraints 

This  section  discusses  the  type  of  security  constraints  supported  by  the  model. 
The  first  section  explains  the  security  constraint  mechanism  and  how  it  can  be 
used  to  represent  simple,  content-based  and  context  security  constraints. 
The  next  section  defines  a  method  used  to  enter  the  constraints  and  shows 
specific  examples  of  its  use  to  register  simple,  content -based  and  context 
security  constraints. 

Both  sections  demonstrate  how  the  classification  meelanism  works  through 
the  use  of  examples  on  tl  e  database  described  in  the  next  two  figure.*.  Figure  1 
gives  the  schema  of  a  sample  database.  The  schema  is  for  a  database 
containing  personnel  information  for  a  company.  The.  arc  two  types  of 
complex  objects  in  the  database.  Employee  type  objects  and  Department  type 
objects.  Each  Employee  object  has  a  field  (instance  variable)  for  the  social 
security  number,  name  and  salary  of  die  employee  and  one  which  is  filled  by  a 
Department  type  objec  t  which  describes  the  department  the  employee  is  a  part 
of.  Each  Department  object  has  a  field  for  the  department  name  (Dname)  and 
project  name  (Project)  of  the  project  the  employees  of  the  depurtmc.it  arc 
working  on  and  a  field  which  is  filled  by  the  Employee  type  object 
representing  the  manager  (Mgr)  of  the  department. 


The  elements  m  the  proposed  security  model  are  discussed  in  the  next  section. 
It  describes  the  role  of  each  object-oriented  element  in  the  security  model.  This 
is  followed  by  a  discussion  of  the  type  of  security  constraints  included  in  the 
model  and  their  representation.  Finally,  there  is  a  dei..  ription  of  the  model 
restrictions. 

4.1.  Security  Entities 

This  section  idemilic::  the  role  played  by  each  entity  in  the  oojccl-oricntcd 
computation  model  in  the  security  model,  The  portions  of  the  object-oriented 
model  discussed  are:  objects,  methods,  messages  ami  method  activations.  The 
object- oriented  model  requires  certain  conceptual  extensions  to  support 
mandatory  security;  these  ate  discussed  as  well. 

Objects  An  object  is  a  collection  of  passive  data  with  an 

associated  sensitivity  level.  The  protected  data  is  the 
object's  instance  variables  and  it  is  disclosed  by  reading 
one  or  more  of  the  variables. 

Methods  A  method  is  a  function  defined  for  execution  on  the  ;laut 

of  a  particular  object  type.  It  is  a  passive  entity.  When 
a  message  is  sent  to  an  object  a  particular  method  is 
selected  and  executed  in  a  method  activation  and  this 
method  activation  is  an  active  entity. 
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Figure  1  -  Sample  Schema  Diagram 

Figure  2  depicts  objects  in  a  database  following  the  schema  shown  in  Figure 
1.  In  die  figure,  boxes  represent  instance  objects,  arrows  point  to  the  value  of 
the  instance  variable,  the  class  of  the  object  is  given  in  the  upper  left  corner  of 
Lhc  object  and  the  upper  right  hand  corner  contains  an  identifier  to  reference  the 
objects  in  the  following  discussion. 
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Figure  2  -  Sample  Database 


4.2,1.  Assigning  Classification  Levels 

livery  object  has  a  sensitivity  level,  Lg.  determined  by  a  set  of  object 
classification  functions.  Hath  function  groups  objects  into  sets  called 
classification  sets  and  gives  each  set  a  sensitivity  level  l.<\  The  meaning  is 
that  the  sensitivity  level  for  disclosing  nil  objects  in  the  classification  set  is 
L(\  Each  object  individually  can  be  disclosed  without  regard  to  Lf.  however, 
the  last  object  disclosed  must  be  classified  at  a  level  which  dominates  L(\  L(* 
is  the  sensitivity  level  of  the  object  determined  by  the  security  consuaims  in 
force.  This  is  only  one  factor  used  to  determine  an  object's  sensitivity  level 
1.q  which  is  used  by  the  reference  monitor  to  determine  me  miovvability  of  an 
access. 

An  object  is  considered  disclosed  to  a  subject  Sj  if  another  subject  Si  which 
cun  write  objects  visible  to  $\  has  read  it.  In  other  words  the  object  is  read 
with  respect  to  a  subject  with  clearance  Lsi  if  it  was  read  by  a  subject  wilh 
clearance  L$2  such  that  L%S2  S  Ls|.  This  definition  is  very  restrictive.  It  is 
requited  to  protect  classification  sets  in  the  ease  of  one  subject  reading  a 
member  of  the  set  and  writing  the  information  into  a  now  object  ol  a  different 
type.  For  example,  consider  the  context  constraint  which  classifies  names  and 
salaries  together  as  Secret  and  otherwise  Unclassified.  If  an  Unclassified  user 
reads  the  name  of  an  employee  and  stores  the  name  in  an  object  of  type 
string',  the  context  constraint  will  no  longer  relate  this  name  to  the  salary  of 
the  employee.  The  definition  of  who  has  read  the  name  object  must  include 
any  other  user  who  is  allowed  to  read  the  special  name  object  of  type  'string'. 
It  must  include  all  subjects  with  current  classifications  which  dominate  tire 
current  classification  of  the  subject  when  the  object  was  read. 

This  mechanism  allows  the  expression  of  simple,  content  and  context 
security  constraints  as  described  in  IDWYE87],  A  simple  constraint 
classifying  all  objects  of  class  Project  as  Secret  is  represented  by  placing  each 
member  of  ’project’  in  a  separate  classification  set  with  a  classification  of 
Secret.  Since  each  set  consists  of  only  otic  object,  the  object  will  immediately 
receive  a  classification  level  lc  of  Secret.  When  this  classification  is  applied 
to  the  sample  database  shown  in  Figure  2  the  classification  in  Figure  3 
results.  This  constraint  produces  only  one  classificat  *n  scl.  The  set  contains 
the  object  ’POT.  Since  it  is  the  only  object  in  the  Secret  set.  its  sensitivity 
level.  Lc.  immediately  becomes  Secret. 


Figure  3  -  Classification  of  Objects  ol  Class  Project  as  Secret  for  Sample  DB 

A  content-based  constraint  specifies  a  set  of  objects  by  means  of  a  predicate 
based  on  the  values  of  some  objects  and  classifies  each  with  the  same 
classification.  For  example,  classify  the  names  of  all  employees  whose  salary 
is  gieater  than  SI 00.000 .00  ns  Secret.  This  type  of  constraint  is  represented 
the  same  as  a  simple  constraint.  Each  name’  which  has  a  corresponding 
’salary’  greater  than  S UX).IXM).(X)  is  placed  in  a  classification  set  by  itself  and 
the  set  is  classified  Secret.  The  two  classification  sets  which  result  from 
applying  lilts  constraint  to  the  database  of  Figure  2  is  shown  in  Figure  4. 
This  constraint  produces  two  classification  sets,  one  containing  ’N04’  and  the 
other  containing  *N03‘.  Since  each  object  is  the  only  object  in  its 
classification  set.  it  takes  on  the  sensitivity  level  of  its  classification  set, 
Secret. 


Figure  4  -  Classification  of  the  Names  of  all  Employees  Whose  Salary  is 
Greater  than  $  1 00,000.00  as  Secret  for  Sample  DB 

A  context  constraint  matches  this  security  constraint  mechanism  exactly. 
Related  objects  ate  grouped  into  classification  sets  and  given  the  sensitivity 
level  Lq  meaning  that  the  sensitivity  level  for  disclosing  all  objects  in  a  set 
is  Lc-  Figure  5  shows  an  example  of  a  context  constraint  classification. 
This  constraint  classifies  the  Project  and  the  Name  or  any  Employee  working 
on  the  Project,  taken  together  as  Secret.  The  constraint  creates  four 
classification  sets.  {  'NOT,  T0F  },  {  N02.  ’PUl’  }.  {  ’N03\  T01’  }  and( 
‘N04',  'POT  }.  Each  of  these  sets  share  the  object  'POT.  This  means  that  as 
soon  as  ’POT  is  read,  all  of  the  Name  objects  become  Secret  and  if  any  Name 
object  is  read.  P01'  becomes  Secret. 
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Figure  5  -  Classification  of  Project  and  the  Name  of  any  Employee  Working 
on  the  Project.  Taken  Together  as  Secret  for  Sample  DB 

The  security  model  is  enforced  by  cooperating  autonomous  objects.  This 
affects  the  way  in  which  security  is  enforced  and  in  particular  how  security 
constraints  are  specified.  In  this  distributed  model  each  object  is  given 
responsibility  for  insuring  the  security  of  its  own  data.  Security  constraints 
must  be  reevaluated  when  a  change  is  made  to  die  database.  For  each  security 
constraint,  one  or  more  objects  must  be  chosen  to  be  responsible  for  doing 
this  reevaluation  whenever  it  is  necessary.  This  responsibility  is  split  between 
the  objects  which  arc  members  of  the  classification  set  and  wlutl  is  called  the 
anchor  object  for  the  constraint.  This  anchor  object  is  not  classified  by  the 
constraints  but  is  used  as  a  reference  {Joint  for  evaluating  the  constraint.  The 
responsibility  of  the  anchor  object  is  to  alert  objects  when  they  arc  classified 
by  the  security  constraint.  The  anchor  object  in  turn  depends  on  objects  which 
the  constraint  is  conditioned  on  to  alert  it  to  changes  in  their  values.  This 
mechanism  allows  the  burden  of  the  constraint  maintenance  to  be  shared 
among  many  objects. 

In  a  simple  or  content -based  constraint  the  anchor  object  is  chosen  to  be 
the  class  object  which  the  classified  objects  arc  instances  of.  For  example  in 
the  constraint. 

Name  in  Employee  where  Salary  >  $100,000.00  is  Secret 

the  anchor  object  is  the  class  object  Name.  The  set  of  objects  to  be  classified 
is  specified  with  respect  to  this  anchor  object.  The  class  object  Name  is 
responsible  for  alerting  each  Name  object  with  a  Salary  over  $100,000.00  that 
it  is  classified  by  the  security  constraint.  Whenever  u  new  Name  object  is 
created  which  satisfies  die  predicate  die  anchor  object  must  alert  it  to  its  new 
classification.  Consider  a  Name  object  created  with  a  Salary  of  S50.000.00, 
the  constraint  will  not  apply  but  the  corresponding  Employee  and  Salary 
object  w  ill  be  made  responsible  to  rc|x)rt  changes  in  their  values  to  the  anchor 
object,  Name.  Later  if  the  Salary  is  updated  to  $  1 10,000.00  the  object  will 
report  this  to  die  class  object  Name  and  the  anchor  object  will  alert  the  Name 
instance  object  of  its  new  classification. 

Simple  and  content-based  constraints  classify  single  objects  not  sets  of 
objects  as  do  context  constraints.  A  context  constraint  must  specify  a 
classification  set.  Each  object  in  the  set  allows  itself  to  be  read  only  when  at 
least  one  odier  member  of  the  set  is  still  unread.  The  last  unread  object  in  the 
set  must  increase  its  sensitivity  level  to  that  specified  in  she  context 
constraint  before  it  is  read.  Instead  of  maintaining  the  constraint  specified 
classification  set,  the  set  of  specified  objects  which  have  not  yet  been  rcaJ  can 
Iv.  maintained.  The  classification  set  is  then  specified  and  maintained  as  an 
ordered  sequence  of  objects.  The  anchor  object  is  responsible  for  alerting  each 
first  object  that  it  is  the  firM  object  ill  a  context  constraint.  The  object  is 
also  given  the  specification  of  the  rest  of  the  ordered  sequence.  Each  object  in 
the  sequence  then  acts  as  an  anchor  object  for  the  next  object  in  the  sequence, 
alerting  it  that  it  is  included  in  the  constraint  and  passing  on  the  specification 
of  the  rest  of  die  ordered  sequence  of  objects.  Consider  the  constraint. 

Name  in  Employee  and  Salary  in  Employee  taken  together  are  Secret. 

The  anchor  object  for  this  constraint  is  the  class  object  Employee,  (this  is  an 
arbitrary  decision).  'Employee'  is  required  to  alert  each  object  which  fills  the 
Name  slot  of  one  of  its  instances  that  it  is  part  of  a  context  constraint.  The 
specifications  for  the  rest  of  the  objects  arc  passed  on  with  this  notification. 
The  Name  object  which  receives  this  information  Uicn  uses  the  specification 
of  the  rest  of  the  ordered  sequence  to  alert  the  prospective  next  objects  in  the 
sequence.  In  this  example  the  Name  ohjcct  determines  its  containing 
Employee  object  and  then  the  Salary  object  contained  within.  This  Salary 
object  is  alerted  that  it  is  part  of  the  context  constraint.  The  Salary  object  is 
the  last  in  the  sequence  and  so  doesn't  need  to  alert  any  further  objects. 


Each  context  constraint  creates  one  or  more  classification  sets.  In  the 
example  above  there  is  one  set  of  objects  for  each  Employee  object  in  the 
database.  If  this  constraint  is  applied  to  the  database  shown  in  Figure  2,  the 
resulting  classification  sets  arc  shown  in  Figure  6.  This  constraint  produces 
four  classification  sets,  {  'NOT,  'SOI'  },  { 'N02',  'S02' ),  {  'N0.T,  ’SO-*'  }  and  { 
'N04\  'S04'  }.  Each  set  has  a  sensitivity  level  o(  Secret.  This  classification 
has  no  immediate  effect  on  the  sensitivity  level,  Lo  of  any  of  die  objects,  if 
however  object  'S03*  is  read  this  constraint  will  cause  L<j  of  'N03'  to  become 
Secret. 
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Figure  6  -  Classification  of  Name  and  Salary  Taken  Together  as  Secret  for 
Sample  DB 

4,2.2.  Specifying  Security  Constraints 

A  set  of  methods  arc  defined  in  all  objects,  sccurityConstraiiUfliLcvel:, 
securilyConstrainU'l:f2:Lcvcl:,  etc.,  which  lake  an  ordered  collection  of 
functions  uud  an  aggregate  sensitivity  level  Lc  as  arguments.  The  functions 
{fl  ...  fnl  arc  defined  as  follows: 

f  l  :  anchor_objcci  object* 

f2-n  •  object  -» object* 

Where  object*  represents  a  set  of  zero  or  more  objects.  The  functions  f{  ...  fn 
arc  used  in  die  following  way  to  define  a  set  S  of  classification  sets. 

Si  »  {  x  I  x  e  f  1(0 Anchor)  ) 

s  =  (  I  y l .  >'2 . yn  i  lyi  6  Si  AJT2  6  f2(yi)  A  ...  Ay„e  rn(y„.|)  J 

Where  OAtichoi  is  the  anchor  object,  the  object  receiving  the  classification 
message.  The  first  function,  Ij,  applied  to  the  anchor  object  produces  die  first 
set  Si  of  objects  in  the  classification  sols.  The  next  object  in  the 
classification  set  results  from  applying  f2  lo  one  of  the  objects  in  S  \ .  This  is 
carried  out  for  all  n  functions  to  create  each  element  of  S. 

The  following  arc  examples  of  how  security  constraints  can  be  represented 
using  the  above  classification  scheme.  We  are  expressing  the  constraints  in  a 
notation  similar  to  SMALLTALK-80  [GOLDH3]  as  described  in  Section  3. 
First  we  will  describe  some  of  the  methods  used  in  the  example; 


Object  Class  Method 

Description 

object 

fill.sSIotiln: 

This  is  a  predicate.  When  used  as 
TillsSlot;  name  In:  employee'.  It  returns 
True  if  the  receiving  object  is  the  value 
of  the  'name'  instance  variable  in  an 
’employee’  object. 

object 

containingObject 

This  method  returns  the  object  which  uses 
the  receiver  as  the  value  of  one  of  its 
instance  variables.  For  example,  if  the 
object  'SOI'  received  the  message  the 
result  would  be  'EOF,  the  employee' 
object  which  'S0F  is  contained  5n. 

class 

insianccsQf 

Returns  the  objects  which  are  instances  of 
this  class. 

class 

with: 

This  message  is  used  as  'Set  with:  a'.  It  is 

.■*cnt  to  the  class  object  'Set*  and  creates  a 
new  set  containing  the  object  'a'. 
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set 

select: 

This  method  dikes  one  argument  which  is 
a  nrcdicate.  It  returns  a  new  set  which 
contains  all  of  the  members  of  the 
original  set  for  which  the  predicate  is  true. 

set 

collect: 

This  method  takes  one  argument  which  is 
a  function  ami  applies  it  to  each  member 
of  the  receiving  set  object.  The  objects 
returned  by  the  function  applications  are 
collected  into  a  new  set  which  is  the 

result. 

employee 

mime 

Returns  the  value  of  the  'name'  instance 
variable. 

employee 

sdary 

Returns  the  value  of  the  'salary'  instance 

variable. 


Below  arc  the  sample  security  constraints: 
Simple  Security  Constraints 
Constraint:  project  in  department  is  Secret 


jrrojcct  securiiyConsirainifl: 

I: Object  I  ( Object  insumcesOf)  select: 

[:ObjectToClassify  I  ObjcclToClussily  fillsSIot:  project 

In:  department] 


Level:  Secret. 


This  constraint  classifies  all  objects  which  fill  the  ‘project’  role  in  'department' 
objects  as  Secret.  Tito  i  ■distraint  is  established  by  sending  the  anchor  object 
project'  die  block  shown  and  die  sensitivity  level  Secrcl.  The  block  fl  first 
computes  die  set  of  instances  of  its  argument.  Elements  of  this  set  arc  then 
selected  for  inclusion  in  the  result  based  on  the  block  which  takes  an  objeci  as 
an  argument  and  returns  True  if  the  object  tills  the  slot  named  project  in  a 
department  object.  This  constraint  would  classify  object  'POl'  from  Figure  2 
as  Secret. 


Content-Security  Constraints 


This  constraint  groups  objects  into  two  element  classification  sets  and  assigns 
the  set  a  sensitivity  level  of  Secret.  The  constraint  requires  of  a  user  reading 
more  than  one  object  in  any  set  to  have  at  least  a  Secret  clearance.  The  class 
object  'employee'  is  the  anchor  and  is  sent  ft,  f2  and  the  sensitivity  level 
Secret.  The  class  object  Employee  is  used  as  the  argument  to  fj  to  compute 
the  first  elements  in  each  classification  set.  The  block  first  creates  a  sot  of  all 
of  the  instances  of  'employee',  in  this  example  the  set  fEOt ,  E02,  EC3,  E04). 
From  this  set  it  creates  a  new  set  by  upplying  the  block  [teach  I  each  name]  to 
each  member.  This  block  returns  the  'name'  of  the  employee  object.  The 
resulting  set  is  (N01,  N02,  N03,  N04),  Given  an  uigumcnl  in  (N01,  N02, 
N03,  N04),  f2.  maps  it  to  the  second  element  in  die  classification  set.  The 
function  finds  the  containing  object  and  then  requests  of  it  the  salary  object.  It 
then  creates  a  set  from  these  objects.  The  resulting  sets  obtained  in  this  way 
me  shown  in  Figure  6. 

These  methods  allow  a  common  method  for  defining  simple,  content-bused 
and  context  constraints.  Simpler  methods  could  be  developed  if  each  type  of 
constraint  were  considered  separately.  For  example,  a  simple  constraint  can 
be  specified  by  supplying  only  the  class  name  of  the  objects  to  be  classified. 
A  content-bused  constraint  needs  in  addition  a  predicate  10  be  evaluated  by 
ihc  objects  to  be  classified. 

4.3,  Model  Restrictions 

This  section  describes  Ihc  security  model  restrictions.  The  restrictions  define  a 
set  of  allowable  object  accesses.  There  tire  four  parts  lo  die  model.  The  first 
part  describes  which  object  accesses  arc  allowed  based  on  llte  sensitivity  level 
of  the  object  and  the  current  security  level  of  llte  method  muking  the  request. 
The  second  part  describes  allowable  assignments  and  allowable  changes  to 
object  sensitivity  levels,  llte  next  section  describes  allowable  assignments  und 
allowable  changes  lo  securiiy  classification  levels  for  methods.  The  filial 
scciion  discusses  llte  cflccl  of  security-inconsistent  database  slates  on 
mandatory  securiiy. 

4.3.  t.  Object  Access 

A  melllod  activation  executing  with  a  current  security  classification  lovci 
l-Scurrcm  is  allowed  lo: 

(1.1)  Read  die  instance  variables  of  an  objeci  with  sensidvity  level  L0 
such  dial  Ln  S  l-Sou r rent- 


Constraint:  name  in  employee  where  salary  >  KXKXX)  is  Secret 

name  sccurityConstraintf  I : 

|:Objeci  I  (  Object  insumcesOf )  select: 
i :  Objee  tToC  I  assi  fy  I 

(ObjeclToClassify  lillsSlot:  name 
In:  employee) 
and: 

(((ObjeclToClassify  containingObjccOsalury) 
>  100000) 

I 

I 

Level:  Secret. 

This  constraint  classifies  all  objects  which  fill  the  'name'  role  in  'employee' 
objects  if  the  corresponding  'sat-  '  is  greater  than  100000.  The  cf.isuraint  is 
established  by  sending  the  cla  ■  ibjcct  'name'  fl  and  the  sens'dvity  level 
Secret.  The  anchor  object  is  the  class  object  name.  The  block  fl  returns  the 
sel  of  instances  of  its  argument  which  satisfy  die  following  block.  Tie  block 
combines  two  predicates  using  the  band'  message.  The  first  is  Tree  if  ihc 
object  fills  the  'name'  slot  in  'employee'.  The  second  determin-s  the 
corresponding  'salary'  objeci  and  tcsls  lo  see  if  its  value  is  greater  than 
UKXXX).  The  effect  of  llte  above  constraint  would  be  to  classify  the  object 
'N03'  as  Secret. 

Context-Security  Constraints 

Constraint:  name  in  employee  und  salary  in  employee  taken  together  arc 
Secrcl 


(1.2)  Modify  llte  instance  variables  of  an  object  with  sensitivity  level  L0 
such  dial  Lscurrenl  £  Lt)  s  Lgclcar- 

In  addition,  pointer  references  arc  restricted  as  follows: 

(1.3)  A  pointer  lo  an  unreadable  object  behaves  exactly  as  a  null  object 
pointer. 

Rule.':  ( 1 .  i )  and  ( 1 .2)  by  themselves  do  not  insure  llte  simple-security  properly 
or  the  ‘-property  |BELL76|  since  llte  levels  of  objects  and  methods  arc 
allowed  to  change  and  these  changes  have  not  yei  been  defined.  The 
maintenance  of  these  properties  can  be  insured  only  utter  examining  die 
mtxlificulion  policy  for  sensitivity  levels  for  objects  and  classification  levels 
for  methods.  This  is  discussed  in  Section  5. 

4.3.2.  Object  Sensitivity  Levels 

Security  classification  rules  determine  sensitivity  levels  for  all  objects  at  uil 
times.  In  ihc  interest  of  maintaining  mandatory  security  some  of  Utesc  derived 
sensitivity  levels  can  not  be  used.  The  following  rules  describe  die  way 
assignments  are  made,  taking  into  account  tire  sciisitvily  level  derived  from 
the  security  constraints  and  concerns  for  information  flow  restriction. 

(2.1)  Objects  arc  assigned  the  lowest  sensitivity  level  Lo  at  object 
creation  time  such  that  Lo  dominates  all  sensitivity  levels  Lj, .. , 
Ln  imposed  by  applicable  securiiy  constraints  and  l-o  dominates 
the  security  level,  Lscurrent,  of  llte  method  activation  creating  the 
objeci.  In  oilier  words  Lq  =  Lscurrem  ilL]  11...  flL,,.1 


employee  sccuriiyConstrjimfl:  l2-2!  T,lc  security  level  or  an  object  can  only  be  increased.  An  objeci 

fiOt'jccl  I  (Object  instanccsOO  collect:  (:cach  1  each  name]  J  classified  with  a  sensitivity  level  of  Lo  can  be  changed  to  level 

12: 

l:p  I  Set  with:  ((p  containingObjecl)  sulury)]  _ 

Level.  Secret. 

1  fl  represents  the  least  upper  bound  defined  on  the  security  classification 
lattice  by  the  partial  ordering  i. 
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Lo'  if  and  only  if  Lo  s  l_o'.  Downgrading  of  objects  must  be 
done  by  trusted  method  activations. 

(2.3)  The  security  level  Lo  of  an  object  can  be  affected  only  by  method 
activations  executing  with  a  current  classification  level  Lscurrenl 
such  that  Lscarreni  5  f-O-  If  this  were  not  the  case  a  covert 
channel  would  exist  since  a  higher  level  subject  could  signal 
information  to  a  lower  level  subject  by  increasing  the  sensitivity 
level  of  an  object  originally  readable  by  the  lower  level  subject, 
thus  malting  it  unreadable.  This  channel  is  pointed  out  in 
[WOOD87).  The  model  restriction  allows  a  subject  with  a 
clearance  level  Ls2clear 10  make  modifications  to  the  security  level 
of  an  object  which  is  visible  to  a  subject  with  a  clearance  level 
1-Slclear  even  when  Lsiclcar is  strictly  dominated  by  Ls2clcar.  as 
long  as  Lsicurrcnt  k  LS2currcnt.  This  approach  decreases  the 
amount  of  over-classification  and  at  the  same  time  eliminates  the 
covert  channel. 

4.3.3.  Method  Activation  Security  Levels 

A  method  activation  executes  with  a  security  classification  level  Lgcurrcnt 
determined  by  two  quantities.  The  first  is  the  clearance  level  Lsdcar  of  the 
security  subject  which  initiated  the  computation,  Lsclcar  is  the  security 
clearance  level  of  a  user  and  applies  lo  all  methods  which  arc  executed  on  the 
user's  behalf.  The  second  quanUty  which  determines  Lscurrcm  is  iho  cunent 
security  classification  level  Lsoriginator  of  the  method  activation  which 
started  this  mcUiod  by  sending  a  message.  Both  of  these  quantities  are  at  least 
conceptually  carried  by  the  message.  A  passive  method  is  combined  with  a 
passive  message  to  create  a  method  activation  which  executes  with  a  security 
classification  level  determined  by  Lsoriginator  and  Lsclcar  as  obtained  from 
the  message.  Below  is  a  set  of  rules  determining  the  current  security 
classification  ol  a  method  activation. 

(3.1)  The  login  method  begins  execution  with  classification  level 
Lscurrcm  =  System  Low. 

(3.2)  A  method  activation  begins  with  a  classification  level  LScurrem  = 
I-Sorigimilor- 

(3.3)  If  an  attempt  to  rcud  an  object  with  sensitivity  level  Lo  such  that 
Lo  S  Lsdcur  fails,  the  clus.-ificalion  level  of  (he  method  will  be 
modified  lo  Lscurrcnt'  such  that  1-Scurrcnl  ~  Lsc.irrcn;  I  1-0 . 

(3.4)  A  method  activation  object  Oma!  is  only  visible  to  another 
activation  object  Oma2  and  vice  versa  if  cither; 

(i )  Omul  originated  execution  of  Oma2- 
(if )  Oma  1  originated  execution  of  Oma3  and  Oma3  is  visible  to 
Oma2- 


Rules  (3.1)  through  (3.3)  insure  that  Lsclcar  will  always  dominate  L.Scurrcnt- 
1-Scurrcnt  shuts  ut  System  Low  um]  if  Lscurrcm  S  Lsclcar  neither  (3.2)  or 

(3.3)  will  make  Lscurrcm  >  I-Sclcar-  Rule  (3.4)  states  that  method  activation 
objects  ;uc  only  visible  to  other  objects  in  the  same  calling  graph, 

4.3.4.  Model  Enforcement  and  Security-Consistent  Database 
States 

Security  constraints  arc  used  to  classify  consistent  entities  only.  At  times 
during  the  creation  or  update  of  an  object  an  entity  can  become  inconsistent. 
When  this  happens  it  is  not  possible  to  immediately  classify  some  of  the 
objects  involved.  This  complicates  security  enforcement  since  it  becomes 
impossible  to  determine  immediately  if  an  operation  can  be  allowed,  The 
problem  is  illustrated  in  the  following  example. 

This  example  is  interested  in  trying  to  create  an  'employee'  object  and  place  it 
in  the  database.  The  employee  object  is  'E03'  from  the  sample  database  shown 
in  Figure  2.  Assume  'Name'  objects  with  corresponding  'Salary'  objects 
greater  than  100K  are  Secret  and  all  other  objects  are  Unclassified.  The 
subject's  current  classification  level  is  Unclassified  and  Its  clearance  level  is 
Secret.  The  steps  in  the  object  creation  are  listed  in  Table  1  along  with  the 
sensitivity  of  the  object  being  created  or  modified  and  Lscurrent.  the  current 
classification  level  of  the  method  activation. 

Action  Qbiect  Sensitivity  Lsenrrent 

1.  Create  employee  object  'E03'  Unclassified  Unclassified 

2.  Store 'E03' in  department  object 'D02'  Unclassified  Unclassified 

3.  Create  social  security  object 'SS03'  Unclassified  Unclassified 


4. 

5. 

6. 

7. 

8. 


Store  'SS03’  in  employee  object  'E03' 
Create  salary  object  'S03' 

Store  'S03'  in  employee  object  EOS’ 
Create  name  object  'N03' 

Store  7403'  in  employee  object  'E03' 


Unclassified 

Unclassified 

Unclassified 

Unclassified 

Secret 


Unclassified 

Unclassified 

Unclassified 

Unclassified 

Secret 


Table  1  -  Steps  In  Creating  an  Employee  Object 


in  steps  1  through  7,  the  database  is  not  consistent.  According  to  our 
assumptions,  only  the  sensitivity  levels  of  Name  objects  are  affected  by  a 
relation  to  another  object  provided  only  in  consistent  objects.  Once  the 
'Salary'  object  is  stored  the  correspondence  between  'N03'  and  'S03'  is 
established  and  'A.  Talbog  becomes  Secret.  At  this  time  the  subject  must 
change  Lscurrcm  10  Secret.  There  is  a  time  between  steps  7  and  8  when  'A. 
Talbot'  has  been  entered  in  the  system  but  not  yet  classified  Secret. 


This  problem  slems  from  the  fact  that  security  constraints  arc  applied  aficr 
each  change  to  an  object  and  not  when  a  consistent  object  has  been  created. 
Tlte  security  constraints  in  the  example  classify  names  with  corresponding 
high  salaries  as  Secret  and  otherwise  they  are  assumed  to  be  Unclassified.  In 
step  7  there  is  still  no  corresponding  salary  for  the  name  'N03'  and  so  it  Is 
assumed  Unclassified.  In  fact,  the  sensitivity  level  of  'N03'  is  unknown 
because  no  specific  security  constraint  applies  to  the  object  when  it  is 
inconsistent. 


Wc  arc  still  investigating  this  problem.  Our  approach  is  to  do  these 
modifications  inside  a  transaction.  A  uansaclion  [DATE84]  groups  individual 
operations  carried  out  on  a  database  lo  bo  considered  as  one  atomic  chango.  A 
transaction  has  two  possible  outcomes,  It  can  be  committed  in  which  case  the 
transaction  completes  and  its  affect  on  (he  datubuse  is  made  permanent.  It  cun 
be  aborted  in  which  cose  the  database  is  restored  to  its  slate  previous  to  the 
beginning  of  the  transaction.  The  transaction  allows  the  individual 
modifications  needed  lo  get  to  a  security-consistent  slate  to  be  considered  one 
unit  of  change.  It  is  described  further  below; 

1.  If  an  object  is  modified  outside  of  a  transaction  it  must  go 
immediately  to  a  consistent  stale,  where  each  object  is  classified  by 
a  security  constraint.  The  modification  must  not  cause  the 
classification  oi  any  object  to  become  unknown. 

2.  If  an  object  is  modified  inside  a  transaction  the  classification  of  an 
object  can  go  through  unknown  suites.  When  a  change  causes  an 
objeet  to  go  from  an  unknown  classification  to  a  known 
classification,  the  validity  of  the  intervening  operations  is  checked, 
if  security  is  violated  the.  transaction  is  aborted  and  the  database 
state  is  restored  to  its  previous  stale. 


This  method  is  outlined  in  ruble  2. 


The  tabic  outlines  the  actions  involved  in  creating  an  employee  object.  Thera 
is  one  extra  column  ill  this  example  which  represents  the  conditions  under 
which  the  action  is  allowed  by  the  security  model.  This  condition  is  based  on 
the  as  yet  unknown  sensitivity  levels.  In  the  table  '-N03  represents  the 
unknown  sensitivity  level  of  the  object  'Nl)3'.  Once  step  9  is  complete  L.fsjoj 
is  found  to  be  equal  to  Secret,  die  condition  or.  step  9  is  not  satisfied  and  the 
uansaclion  must  be  aborted. 


5.  Model  Properties 

This  section  discusses  properties  of  the  security  model.  We  don't  attempt 
formal  proofs  of  these  properties  but  rather  use  informal  arguments  to 
demonstrate  the  properties.  In  (he  future  wc  hope  to  develop  a  formal  model 
and  prove  these  properties  at  that  time 

5.1.  Simple  Security  Property 

The  simple  security  property  slates  that  a  subject  with  a  current  security 
classification  lcvol  Ls  is  not  allowed  lo  read  an  object  with  a  sensitivity  level 
Lo  such  that  Lo  >  Ls.  In  the  notation  used  in  this  model  it  is,  a  subject  with 
clearance  level  LSclcar  is  not  allowed  to  read  an  object  with  sensitivity  level 
Lo  if  Lo  »  Lsclear.  This  is  ensured  by  restriction  (1.1)  from  the  previous 
section  along  with  the  fact  that  at  all  times  Lseurrent  s  T-Sclcar-  This  follows 
from  restrictions  (3.1),  (3.2)  and  (3.3). 
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Sffii! 

Action 

Ohjcel  Sensilivilv 

Lscurrcnl 

Allowed  nn  Cnnililmn 

1. 

Start  Transaction 

2. 

Create  employee  object  'E03' 

Unclassified 

Unclassified 

3. 

Store  'E03'  in  department  object  'D02' 

Unclassified 

Unclassified 

4. 

Create  social  security  objccl  'SS03' 

Unclassified 

Unclassified 

5. 

Store  'SS03'  in  employee  object  'E03' 

Unclassified 

Unclassified 

fi. 

Create  salary  objccl  'S03' 

Unclassified 

Unclassified 

7. 

Store  'S03'  in  employee  object  'EQ3' 

Unclassified 

Unclassified 

8. 

Create  name  objccl  'N03' 

LN03 

LN03 

Ln()3  £  Secret 

y. 

Stoic  'N03'  in  employee  objccl  'EU3' 

LN03 

LN03 

LN03  £  Unclassified 

10. 

Abort  Transaction 

Tabic  2  •  Steps  in  Craning  nn  Employee  Object  with  Deferred  Classification 


5.2,  ♦•Property 

The  ••properly  slates  that  a  subject  with  current  security  classification  level 
t.<j  can  nut  write  objects  with  sensitivity  level  L0  such  that  Lq  <  Lg.  The 
pro|X)scd  model  allows  a  subject  to  write  objects  with  sensitivity  levels  below 
EScIciu  US  long  as  the  subject  docs  not  have  information  from  objects  whose 
level  strictly  dominates  the  object  written.  Evidence  the  model  enforces  this  is 
based  on  two  facts,  the  first  that  LScurrent  dominates  the  sensitivity  level  of 
all  information  the  method  lias  obtained  and  second  the  method  activation  can 
not  write  or  create  objects  such  that  Lscurrent  >  Lq  (front  (1.2)). 

The  information  accessible  to  a  method  activation  can  come  from  its  instance 
variables,  information  about  its  culling  contest  and  information  available 
about  the  existence  of  unrcauublc  objects.  The  information  accessible  from 
instance  variables  is  covered  by  point  (3.3),  l-Scuircnt  dominates  the 
sensitivity  level  of  ull  objects  which  line  directly  read  by  a  method  activation. 

Information  read  by  the  calling  method  activation  can  be  passed  on  by  the 
mere  fact  that  the  method  is  executed.  For  example,  in  the  computation 
below, 

.SccrctObjcel  ilTrue:  [  UnelussificdObject  ah  Answer  put:  True] 

the  execution  of  Ihe,  true  block  is  predicated  on  the  information  in 
SecrelOb.iecl.  This  method  activation  is  restricted  to  start  execution  at  the 
eliissilication  level  of  its  originator  by  restriction  (3.2),  Secret  in  this  ease. 
This  ensures  that  Lsenrrent  dominates  the  level  of  its  originating  activation 
level  and  thus  it  dominates  the  sensitivity  level  of  all  information  Its 
execution  could  lie  predicated  an.  This  also  address  the  problem  of  information 
being  transferred  when  die  SceretObjoct  is  False,  since  the  program  can  not 
store  information  when  the  value  is  True  and  it  doesn't  attempt  to  when  the 
value  is  False,  diis  program  will  not  pass  information  about  SccrclObjcct. 

Information  about  the  existence  of  objects  is  given  io  a  method  activation 
when  it  can  distinguish  between  null  objects  and  objects  it  is  not  allowed  to 
read.  This  transfer  of  information  is  disallowed  by  (1.3). 

5.3.  Message  Safely 

Sending  and  receiving  messages  can  not  violate  mandatory  security.  This  will 
lie  discussed  in  two  parts.  Sending  a  message  to  licgin  cxcculion  of  u  method 
is  discussed  first,  followed  by  a  discussion  of  the  object  returned  on 
completion  of  the  niedtod  execution. 

A  message  is  sent  by  an  active  method  activation,  Ml,  to  a  passive  object 
causing  another  method  activation,  M2,  to  begin  execution.  M|  is  executing 
with  a  clearance  level  of  Lsc|car  and  a  current  classification  level  of 
LS  Icurrenl-  From  restrictions  (3.2)  and  (3.3)  it  can  be  seen  that  the  method 
activation  M2  is  started  with  the  same  current  authority  level  and  the  same 
clearance  level.  Any  information  wtiich  is  translcrrcd  to  the  method  activation 
M2  by  beginning  its  execution  is  acceptable  since  both  methods  execute  with 
die  same  current  classification  level. 

Restriction  (3.3)  places  the  upper  bound  for  Ls2current  to  be  Lsdeur-  Thus 
die  ujjjicr  bound  on  any  object  returned  to  M  ]  by  M2  is  also  Lsdear.  by  (3.3) 
and  (1.2).  This  object  can  always  be  read  by  M(  because  of  (3.3)  and  the  fact 
that  die  same  level  Tor  Lsdear  applies  to  both  method  activations.  Security 
can  only  be  violated  if  M2  cun  return  higher  level  information  to  M)  and  M] 
docs  not  increase  its  current  classification  level  to  match  that  of  M2.  If  Mi 
attempts  to  read  the  object  returned  it  will  raise  its  classification  level 
according  10  (3.3)  and  security  will  not  be  violated.  If  M]  docs  not  read  the 
object  it  will  not  receive  the  information  and  security  will  again  not  be 
violated. 


5.4.  Storage  Channels 

This  section  wilt  discuss  covert  storage  channels.  The  main  threat  of  a  covert 
channel  in  this  model  comes  from  covert  signalling  using  the  sensitivity 
levels  of  objects.  This  problem  con  exist  in  security  models  which  allow  the 
sensitivity  levels  of  objccls  to  change.  The  signalling  is  done  by  allowing  a 
high  level  subject  to  modify  the  sensitivity  levels  of  objccls,  making  them 
either  visible  or  invisible  to  a  lower  level  subject.  We  have  added  restrictions 
to  the  model  to  disallow  this  signalling.  Method  activations  arc  objects  but 
have  different  restrictions  on  them  than  normal  objccls.  First  the  restrictions 
for  normal  objects  will  be  discussed  and  then  the  special  case  of  method 
activations  is  discussed. 

To  disallow  signalling  through  die  sensitivity  level  of  normal  objects, 
restriction  (2.3)  was  added.  This  forbids  a  high  level  subject  from  modifying 
die  sensitivity  level  of  an  object  visible  to  a  lower  level  subject  indirectly. 
This  can  ulso  take  place  directly  if  the  subject  tries  to  modify  a  lower  level 
object,  ami  is  disallowed  by  (1.2).  It  takes  place  indirectly  when  u  change  to  a 
higher  level  objccl  causes  the  security  constraint  derived  sensitivity  level  Lc 
to  change.  This  is  a  natural  restriction  If  the  security  level  of  the  object  is 
actually  recorded  in  the  object  and  the  method  actlvution  making  u  change  to 
an  object  supplies  the  authority  to  uptime  ull  changed  sensitivity  levels.  This 
ensures  that  a  method  uctlvution  Mi  can  only  change  the  visibility  of  an 
object  visible  to  another  method  uelivatlon  M2  if  Ls  1  clear  £  ES2elcur-  This 
transfer  of  information  is  Icgiliiliutc  and  docs  nol  violate  security. 

Method  activations  violate  the  ubovc  restriction.  Restriction  (3.3)  ullows  the 
change  of  a  method's  security  level  conditioned  on  the  existence  of  an  object 
with  u  higher  classification  level,  litis  can  ullow  a  covert  storage  channel  if 
another  method  uctivulion  cun  monitor  the  classification  level  of  Ihe  method 
activation.  A  method  activation  is  an  objccl  which  changes  ils  visibility  to 
other  method  activations  depending  on  its  sensitivity  or  classification  level. 
Restriction  (3.4)  was  added  lo  eliminate  this  possible  channel.  Method 
activations  nrc  allowed  10  see  oilier  method  activation  objccls  in  the  same 
culling  graph  since  this  muy  be  necessary  i"  practice.  This  does  not  cause  a 
channel  since  the  method  activation  object  of  method  activations  in  the  same 
calling  graph  is  always  visible  to  anoiher  method  nctivation  in  the  same  nee 
and  will  cause  Lscurrcnl  an  observing  method  to  rise  to  the  sensitivity 
level  of  the  uctivulion  being  observed,  litis  is  because  they  share  the  sumc 
value  for  Lsclcar.  (-sc«  discussion  of  message  safely  above). 

6.  Conclusion 

We  have  proposed  a  security  model  for  u  Multilevel  Secure  Object-Oriented 
System.  The  mode  l  is  posed  in  terms  of  an  object-oriented  computation  model 
incorporating  distributed  co-operating  objects.  Each  object  is  assumed  to  be  a 
self-contained  computing  element  whose  only  interaction  with  other  objects  is 
through  sending  and  receiving  messages. 

The  model  contains  extensions  to  support  the  data  classification  necessary  for 
use  in  MLS/DBMS,  This  security  model  ullows  a  subject  to  act  with  the 
lowest  classification  level  necessary  to  accomplish  a  task  and  thus  avoid  over- 
classification  of  data  in  the  presence  of  updates.  This  allows  dula  classification 
to  follow  a  set  of  security  constraints  defined  on  data  containers  and  not  the 
security  clearance  level  of  the  subject  making  the  updates. 

One  distinct  advantage  of  our  approach  is  that  the  object-oriented  compulation 
model  provides  a  uniform  treatment  for  all  objects  in  the  system.  This  sim¬ 
plifies  the  statement  of  a  security  model  and  the  subsequent  design. 

There  arc  many  issues  which  remain  to  be  examined.  Although  coven  storage 
channels  in  the  proposed  security  model  have  been  considered  we  have  not  as 
yet  performed  a  formal  analysis  of  these  storage  channels.  The  practicality  of 
some  of  the  methods  proposed,  such  as  the  deferred  enforcement  for  sccurity- 
inconsistem  database  states  need  to  be  determined. 
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Wc  in  lend  to  further  develop  this  security  mode!  and  analyze  its  security 
properties  more  farmaliy.  At  that  time  wc  will  consider  the  problem  of 
system  complexity  and  verification,  Wc  also  intend  to  implement  the  model 
in  an  object-oriented  system  to  investigate  the  feasibility  of  the  model  and 
performance  issues  related  to  its  implementation. 
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A  security  policy  and  a  formal  policy  model  for  the 
security  properties  of  an  internet  system  are 
presented,  The  model  is  a  result  of  the  resolution  of 
specific  system  design  issues,  environmental  attri¬ 
butes,  security  requirements  and  ihe  desire  to  for¬ 
mally  specify  and  verify  the  internet  system  design 
with  respect  to  specific  security  constraints, 
Although  the  modeling  approach  is  general  and 
applicable  to  many  systems,  the  actual  resulting 
model  is  system-specific. 

Introduction 

In  this  |mpcr,  we  iloeiinicnl  u  security  policy  and  formal 
policy  model  for  an  internet  system.  We  give  a  rationale 
for  the  model  mu)  its  development  with  respect  to  related 
requirements  from  the  Dal)  Trunted  Computer  System 
Evaluation  Criteria,  Roll  5200.2S-.STI)  [l).  The  model  pro¬ 
vides  a  view  of  the  internet  system  ns  a  whole  and  not  as  a 
collection  of  components. 

Several  kinds  of  security  models  have  been  described  in 
recent  papers  [2,3,-lj.  The  specific  kind  of  security  model 
one  would  use  is  driven  by  the  functionality  of  the  target 
system  [5j.  Such  systems  include  operating  systems  and 
their  kernels,  network  components  with  spc-cilie  functional 
requirements,  networks  themselves  and  data  base  systems, 
1  lu-sst*  are  being  analyzed  from  a  formal  modeling  point  of 
view,  Adaptation  of  any  single  security  model,  such  as  the 
Bell-LaPadula  model  [Oj,  for  all  targets  may  not  be 
appropriate  because  of  the  variety  of  analyses  and  particu¬ 
lar  requirements  of  interest. 

Many  models  [2,3,‘f.G|  describe  system  security  in  terms 
of  states  (or  state-transitions)  of  the  system.  The  use  of  a 
state  oriented  model  forces  an  order  on  the  events  of  a  sys¬ 
tem.  In  tue  ease  oi  a  system  that  provides  a  datagram  ser¬ 
vice,  one  cannot  depend  on  the  order  of  the  arrival  and 
departure  of  datagrams  at  an  individual  component  or  at 
the  system  as  a  whole.  The  security  properties  of  the  com¬ 
ponents  of  the  datagram  system  as  well  as  the  datagram 
system  itself  must  therefore  be  independent  of  these 
aspects.  The  model  we  present  is  independent  of  the  order 
of  the  datagrams  as  they  pass  through  the  system. 

Background 

At  the  fall  1987  SIGSAC  conference  at  UCLA,  J.  Millen 
summarized  reasons  for  modeling  systems  and  what  system 


models  are  to  accomplish  [7|.  First,  models  are  constructed 
to  provide  a  descriptive  capability  that  can  be  used  to  iden¬ 
tify  the  important  concepts.  Second,  models  are  con¬ 
structed  to  provide  a  general  mechanism  to  analyze  these 
important  concepts.  Third,  models  arc  constructed  to  pro¬ 
vide  a  mechanism  for  obtaining  opecilic  solutions.  They  are 
to  be  used  to  answer  questions  about  the  system. 

The  following  applies  those  observations  to  security 
models.  First,  models  are  used  to  describe  the  security  pro¬ 
perties  of  the  system.  Second,  they  are  used  to  provide  a 
means  to  analyze  these  security  properties.  Third,  they  are 
used  to  provide  a  mechanism  to  answer  questions  about  the 
security  of  the  system.  Security  models  also  are  used  to 
establish  the  basis  for  the  formal  verification  of  the  system 
security  design.  In  this  paper  we  present  an  internet  formal 
policy  model  and  illustrate  these  modeling  observations. 
We  provide  a  general  modeling  approach  and  oiler  a  specific 
internet  policy  model. 

Ihe  Multinet  Chileway  System  security  policy  model 
provides  a  description  of  the  security  properties  of  a  system 
of  packet  switch  nodes  as  a  whole  system.  The  model  does 
not  deal  just  with  a  node  within  the  system,  nor  just  the 
software  portion  of  the  corresponding  Trusted  Computing 
Basejlj.  This  is  because  a  user  of  an  internet  system  is 
interested  ill  what  the  entire  system  will  do  with  his  infor¬ 
mation,  from  visible  interface  to  visible  interface.  His 
interest  will  not  be  satisfied  merely  by  telling  him  about  tin- 
properties  of  some  piece  of  software  embedded  deeply 
within  the  internet  system.  The  focus  of  the  formal  policy 
model  is  protection  against  compromise  together  with 
specific  integrity  constraints  that  support  protection  against 
compromise. 

The  formal  policy  model  defines,  as  important  from  a 
security  point  of  view,  the  notions  of  information  units, 
their  acceptance  into  the  system,  the  associated  internal 
processing  (termed  derivation,  which  includes  information 
unit  isolation  by  security  label)  and  their  delivery  out  of  the 
system.  A  definition  of  system  security  is  then  made  in 
these  terms.  Tne  model  formulation  is  expressed  in  terms 
of  what  information  is  allowed  to  flow.  It  is  not  expressed 
in  terms  of  states  and  state-transitions  (see  Sections  3.  4). 
This  formulation  defines  a  general  mechanism  for  the 
specification  and  analysis  of  the  security  properties  of  an 
internet  system.  By  making  specific  choices  within  the  com¬ 
ponents  of  the  formal  policy  model,  distinct  policies  can  be 
specified  and  implemented.  This  includes  a  portion  of  a 
DoD  policy  expressed  as  a  “dominance”  (l)  relation  on  sen¬ 
sitivities.  The  model  has  been  used  to  provide  a  means  to 
establish  consistency  among  the  security  properties. 
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Multinet  Gateway  System  and  Environment  Considerations 

An  internet  system  is  a  collection  of  gateways  intercon¬ 
nected  by  networks  that  provides  a  datagram  service  to 
Hosts.  To  set  the  framework  for  the  policy  itself,  a  brief 
discussion  is  provided  of  the  Multinet  Gateway  System 
(MGS),  its  environment  and  related  security  concerns.  The 
reader  is  encouraged  to  read  (8)  for  additional  background 
information.  The  internet  system,  security  policy  and  for¬ 
mal  policy  model  are  described  and  illustrated  in  this  paper 
by  direct  usage  of  the  MGS  concepts  and  term  urology. 

The  purpose  of  lire  MGS  is  to  increase  inter-operability 
and  survivability  of  DoD  communications  networks  and  to 
provide  secure  commnuicntioirs.  increased  interoperability 
is  achieved  by  allowing  Hosts  on  different  networks,  with 
different  network  protocols,  to  exchange  data  without 
resorting  to  exceptional  procedures.  Survivability  is 
achieved  by  providing  the  capability  to  use  public  networks 
as  transfer  nteehauisins  to  reestablish  l)ol)  internet  connec¬ 
tivity.  Secure  communication  is  achieved  by  a  combination 
of  Inbei-lmsed  access  control  mechanisms,  information  isola¬ 
tion  and  processing  separation.  Kner.vption  is  provided 
where  necessary. 

In  l,’igure  1,  we  show  a  configuration  of  a  MGS,  the 
attached  networks  and  their  Hosts.  The  eouligu ration  con¬ 
sists  of  a  MGS,  together  with  Hosts  and  Wild  Networks 
external  to  tlm  MGS,  Hosts  are  connected  to  the  MGS  via 
ICnd  Networks.  Neither  Hud  Networks  nor  Hosts  are  under 
the  control  of  the  MGS.  The  system  boundary  of  the  MGS 
is  identified  in  the  figure.  It  is  necessary  to  identify  ami 
describe  the  security  eharneteristirs  expected  of  the  MGS 
' by  the  Hosts  and  interconnecting  networks,  as  well  as  the 
characteristics  expected  of  the  Hosts  and  interconnecting 
networks  by  the  MGS.  lienee,  these  characteristics  and 
assumptions  form  the  basis  for  the  MGS  security  policy. 

The  MGS  consists  of  MG  NODUS  and  Transport  Net¬ 
works  connecting  the  MCI  NODI'IS.  Two  aspects  of  the 
lignre  are  to  be  noted  for  modeling  purposes.  First,  the 
MGS,  not  just  a  node,  is  to  be  identified  by  the  formal 
model  as  a  single  entity.  Second,  the  Transport  Networks 
provide  a  private  subnet  that  is  to  be  viewed  as  inside  the 
MGS  and  lienee  under  its  control.  One  can  achieve  this 
result  by  actually  placing  the  Transport.  Networks  inside  a 
physical  boundary  completely  under  the  control  of  the  MGS 
or  one  can  use  some  means,  say  encryption,  to  guarantee 
that  MGS  t ralHe  across  some  resource  shared  with  other 
systems  (i.e.,  the  Transport  Networks)  is  isolated  from  those 
other  systems.  This  is  the  basis  for  a  secure  channel  within 
the  MGS.  A  secure  channel  is  a  generalization  of  the 
“trusted  path"  concept  as  described  in  jl).  A  secure  chan¬ 
nel  is  realized  by  specilic  mechanisms  that  allow  the  com¬ 
munication  of  sensitive  information,  both  within  a  Multinet 
Gateway  Node  and  among  gateway  nodes.  A  Host  con- 
neeted  to  a  Transport  Network  does  not  have  access  to  this 
secure  channel. 

Finally,  in  providing  the  datagram  service  for  end-users, 
additional  information  is  required  to  be  handled  by  the 
MGS  that  is  not  end-user  data.  F.xamples  i 1 1 c I ■  * r  1  o  specific 
protocol  information  or  control  information,  't  lie  system, 
therefore,  peeds  to  distinguish  between  these  two  types  of 
information. 
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Figure  1.  The  Multinet.  Gateway  System  As  an  Internet 


Security  Policy 

Perimeters  and  Policy 

In  the  specification  of  the  security  policy,  security  responsi¬ 
bilities  are  allocated  to  the  components  of  MGS,  Lind  Net¬ 
works  and  Hosts.  We  use  the  notion  of  a  perimeter  enclos¬ 
ing  various  components  to  bound  the  security  properties  of 
the  components.  There  are  two  perimeters  of  importance 
for  the  Mtilliuel  Gateway  System:  the  Security  Perimeter 
and  the  (Vrtilicalion  Perimeter. 

The  Security  Perimeter  of  the  MGS  extends  to  the  Inter¬ 
net  Protocol  (IP)  layer  of  protocol  on  a  Host,  This  is 
because  Hie  MGS  provides  an  IP  datagram  service,  and 
because  tie'll  Iter  Find  Networks  nor  Hosts  are  under  the  con¬ 
trol  of  the  MGS.  For  example,  a  Host  and  an  Find  Network 
are  to  provide  the  correct  security  sensitivity  of  each 
datagram  sent  to  the  MGS.  The  security  perimeter 
extends,  therefore,  beyond  the  system  boundary  of  the 
MGS.  These  assooin l <■<  1  assumptions  and  security  <dmi';ir- 
terislies  are  to  be  included  in  the  internet  security  policy, 
and  consequently,  included  in  the  formal  specification. 

The  Ccrlilication  Perimeter  encompasses  the  internet 
security  relevant  functions.  The  (Vrtilicalion  Perimeter  is 
contained  within  Hie  Security  Perimeter.  For  the  MGS 
Certification  lillbrt,  security  assertions  arc  made  and  being 
proven  (verified)  concerning  security  relevant  functions  that 
are  within  the  Certification  Perimeter.  Security  assump¬ 
tions  are  made  also  about  security  re  levant  functions  out¬ 
side  the  Certification  Perimeter,  but  within  the  Security 
Perimeter. 

The  MGS  assumes  security  responsibility  for  Host  data 
at  a  MGS  Port.  This  Port  is  the  interlace  between  the  laid 
Network  and  the  MGS.  ]  he  collection  of  MGS  Ports  estab¬ 
lishes  the  MGS  Oertilieation  Perimeter,  which  is  the  system 
boundary  and  identified  in  Figure  1.  The  MGS  Security 
Policy,  as  seen  by  Hosts,  is  defined  with  respect  to  this 
Ccrlilication  Perimeter. 

The  MGS  implements  a  security  policy  based  on  the 
DoD  Security  Policy.  The  enforcement  of  the-  security  pol¬ 
icy  depends  upon  a  combination  of  administrative  pro¬ 
cedures  and  technical  enforcement  mechanisms.  Adminis¬ 
trative  procedures  are  necessary  to  determine  and  validate 
tlie  associated  security  attributes  of  each  Host  and  assign 
those  security  attributes  to  the  appropriate  MGS  Port. 
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Technical  enforcement  mechanisms  are  then  used  to  ensure 
that  all  data  exchanged  via  the  MGS  is  always  mediated 
against  these  security  attributes  and  Unit  the  security  attri¬ 
butes  are  protected  against  unauthorized  modification, 
i  lasts  are  expected  tc>  have  a  wide  range  of  security  altri- 
hutes  Of  concern  here  are  those  Host  security  attributes 
related  to  the  exchange  of  data  through  the  MGS.  These 
Host  specific  security  attributes  must  be  converted  into  a 
uniform  set  of  Sensitivity  levels,  to  ensure  that  there  is  con¬ 
sistency  in  Sensitivity  level  naming  conventions. 

Multilist  Gateway  System  Security  Policy 

The  MGS  Security  Policy  encompasses  Protection  Against 
Compromise,  Integrity ,  Provision  of  Service,  and  Accounta¬ 
bility.  The  full  policy  sin  lenient  given  in  |0).  In  particu¬ 
lar,  the  Protection  Against  Compromise  Policy  is  one  of 
assuring  the  secrecy  of  the  information  within  datagrams 
handled  by  the  MGS.  Related  to  this  are  the  integrity  con¬ 
siderations  iliui  are  in  direct  support  of  t lie  maintenance  of 
thnl  secrecy.  The  organization  of  Hie  statements  emphasize 
the  relationship  between  n  restricted  form  of  integrity  and 
the  overall  policy  for  Protection  Against  Compromise, 
■’since  tile  scope  of  t in-  formal  model  is  only  on  the  Protec¬ 
tion  Against  Compromise  together  with  specific  integrity 
consi  minis,  we  do  not  document  the  full  Accountability 
Policy  or  the  Provision  of  Service  Policy  in  iliis  paper. 

Protection  Against  (tompromisc:  The  intent  of  the 
MGS  Security  Policy  for  Protection  Against  Compromise  is 
that  in  form  a  lion  Mowing  through  the  MGS  will  not  he  sent 
to  Hosts  and  Hud  Networks  that  arc  not  allowed  to  see  that 
information.  The  exchange  or  transport  of  information 
between  Hosts  ami  the  MGS  shall  he  either  end-user  infor¬ 
mation  or  non  end-user  information.  The  policy  of  Protec¬ 
tion  Against  Compromise  consists  of  the  following  rules: 

data  skikwy 

a,  The  security  policy  shall  provide  for  the  control  of 
information  within  datagrams  based  on  the  labeling  of 
information. 

h.  Phis  policy  refers  to  end-user  information  at  the  MGS 
certification  pcrimcLcr. 

c.  I’lie  unit  of  data  exchange  between  Hosts  and  the 
Mulliimi.  Gateway  System  for  cml-user  information 
shall  lie  termed  all  information  unit. 

d.  I  he  imil  of  data  exchange  between  Hosts  and  the 
iVltilti net  Gateway  System  for  non  end-user  informa¬ 
tion  shall  be  termed  a  nun  information  unit, 

e.  There  shall  be  the  notion  of  a  Sensitivity  level  associ¬ 
ated  with  each  information  unit  that  is  to  rellect  the 
Sensitivity  of  the  information  unit.  The  Sensitivity 
level  shall  be  realized  via  a  senility  label.  The  sccu- 
ritji  label  shall  consist  of  a  security  classification  and  a 
set  of  .security  categories. 

f.  Hosts  may  lie  authorized  to  send  a  rid  receive  data  at 
more  than  one  Sensitivity  level.  Associated  with  each 
Mult  met  Gateway  System  Port  is  one  or  more  seeuriti/ 
labels  authorized  ft  r  the  Hosts  connected  to  that  port 
via  an  Hud  Network.  There  may  be  separate  sets  of 
security  labels  for  incoming  and  outgoing  ports. 

g.  It  shall  he  possible  to  associate  a  security  label  with 
each  information  unit  as  it  enters  a  port. 

h.  'I  lie  security  label  associated  with  an  infor,  uiliun  amt 
accepted  into  the  System  '■hall  lie  one  of  i  he  security 


labels >  associated  with  the  port  on  which  the  unit  was 
received.  Otherwise,  the  information  unit  will  not  he 
r  -copied. 

i.  Information  unit--,  may  be  transformed  as  they  pass 
through  the  system.  The  transformations  will  be  lim¬ 
ited.  however,  so  that  data  from  one  or  more  informa¬ 
tion  units  are  comoined  into  one  information  unit  via 
a  transformation  only  when  the  associated  security 
labels,  are  equal.  The  security  label  of  the  result  is  to 
equal  the  security  label  of  Hie  information  units  being 
transformed.  The  resulting  unit  is  said  to  be  Derive, i 
Prom  tlie  associated  information  units  being 
transformed. 

j.  If  an  information  unit  is  delivered  to  a  port  for 
transmission  to  a  Howl,  then  (1)  it  was  Derived  Prom 
information  units  accepted  into  the  system  and  (2)  the 
security  label  associated  with  this  unit  is  one  of  the 
security  labels  associated  with  the  Destination  port. 
Otherwise,  it  will  not  be  delivered. 

k.  Information  unils  enter  and  leave  the  MGS  only  via 
Knd  Networks. 

l.  A'on  information  units  received  by  tlie  MGS  will  not 
compromise  any  information  in  information  units  ami 
no  non  information  unit  sent  out  a  MGS  port  will  con¬ 
tain  information  from  an  information  unit. 

The  above  policy  statements  can  lie  summarized  as  fol¬ 
lows:  The  security  label  associated  with  nil  information  unit 
is  not  lo  lie  changed  while  the  unit  is  inside  the  system,  tlie 
association  between  security  label  and  data  is  to  be  main¬ 
tained  throughout  tlie  system,  and  data  from  two  dilferent 
information  units  can  be  combined  inside  the  system  only 
wlii'ii  the  associated  security  labels  arc  the  same.  An  infor¬ 
mation  unit  will  lie  allowed  lo  eater  (leave)  the  system  only 
if  ail  associated  port  possesses  a  security  label  set  com |m ti¬ 
lde  with  the  security  label  the  information  unit.  Further, 
there  shall  be  no  mixing  of  information  units  with  non  infor¬ 
mation  umls. 

The  policy  itself  is  qnile  general  and  can  be  used  to 
describe  a  number  of  policies  for  potentially  ditfurent  appli¬ 
cations.  We  give  a  .summary  of  examples  of  this  in  .’section 
5. 

INTWilllTV  IN'  SIMMS  HIT  of  DATA  SKrltl'.C  Y 
The  Miiltiiicl  Gateway  Integrity  Policy  is  based  on  the 
notion  of  information  unit  described  above.  The  Integrity 
Policy  requires  lhat  information  Mowing  out  of  the  MGS  is 
equivalent  to  information  rend  into  I  he  MCIS.  The  integrity 
Policy  provides  the  explicit  definition  of  the  Derived  Prom 
relationship  mentioned  above.  The  terms  used  in  the  policy 
are  the  same  as  those  for  Protection  Against  Compromise. 
Tlie  Integrity  Policy  consists  of  the  following  rifies: 

a.  This  policy  refers  to  information  at  the  MGS 
certification  perimeter. 

1).  Such  information  is  embodied  in  information  units,  as 
specified  in  the  policy  for  Protection  Against 
Compromise. 

e.  An  information  unit  delivered  from  an  MGS  must  be 
Derived  prom  at  least  one  information  unit  accepted 
into  the  MGS.  (Note  that  this  statement  is  related  to 
statements  (h)  and  (i)  of  the  Protection  Against 
Compromise  Policy.) 

d.  The  delivered  information  unit  must  satisfy  one  of  the 
following  properties: 
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1.  It  must  be  the  same  as  an  information  unit 
accepted  into  the  MGS, 

2.  Us  contents  must  be  contained  in  an  information 
unit  accepted  into  the  MGS,  or 

-ts  contents  are  a  combi  nation  of  information 
units  accepted  into  the  MGS. 

The  MGS  is  delincd  to  be  Secure  with  respect  to  Pro¬ 
tection  Against  Compromise,  if  at  nil  times,  every  informa¬ 
tion  unit  ever  si  by  the  system  to  a  port  for  delivery  to  a 
I  lost  satisfies  the  Data  Secrect /  and  Integrity  statements 
above. 

A  distinct  integrity  model  is  not  provided.  Only  these 
statements  related  to  integrity  are  formally  modeled  and 
verilied  and  then  only  within  the  context  of  the  model  for 
protection  against  compromise. 

Accountability :  The  MGS  Accountability  Policy  refers 
only  to  events  that  lake  place  inside  the  MGS.  The  events 
that  will  he  monitored  tire  those  that  either  affect  the  seeu- 
rily  of  the  system  or  represent  an  attempted  security  viola¬ 
tion.  These  events  will  lie  logged  In  a  protected  fashion  and 
made  accessible  to  appropriate  operators  of  the  MGS. 
Since  the  MGS  node  is  an  Internet  Device  acting  at  the  il’ 
level,  by  its  nature  it  is  a  best  effort  datagram  forwarding 
device.  The  associated  policy  statement  is  that  the  MGS, 
within  tlie  limits  of  the  IP  protocol,  will  provide  a  best, 
elfort  datagram  forwarding  service  in  getting  the  accounta¬ 
bility  information  to  the  appropriate  audit  gathering  facil¬ 
ity. 

Policy  Htutc.nic.nl:  ,'.'(iS  Security.  The  MGS  is  said  to  be 
SECURE  if  is  it  secure  with  respect  to  both  the  Policy  on 
Protection  Against  Compromise  and  the  Policy  on  Accoun- 
t  ability. 

It  is  Important  to  note  that  the  formal  model  (given  in 
Section  -I)  its  well  as  tin;  formal  specification  and  its 
verification  is  the  basis  for  increased  assurance  at  I  lie  A I 
level  (ij  that  tile  running  MGS  satisfies  the  Policy  on  Pro 
lection  Against  Compromise. 

MCS  Model  of  Policy .  Narrative 

In  this  section,  ive  present  a  narrative  description  of  the 
Mullinet  Gateway  System  Security  Policy  Model.  The 
model  is  one  one  of  an  external  view  of  the  system.  The 
model  is  based  on  identified  terms,  a  collection  of  security 
assertions  about  these  terms,  and  specific  relationships 
among  them. 

The  formal  description  of  the  properties  of  the  system, 
on  which  this  narrative  description  is  based,  is  given  in  Sec¬ 
tion  |.  A  discussion  of  several  consequences  of  the  formal 
model  and  how  various  security  policies  can  be  described 
using  the  model  are  given  in  Section  !>. 

Primitive  Terms 

The  motivation  and  security  policy  specification  of  the  pre¬ 
vious  sections  have  been  given  in  rather  concrete  terms. 
The  formal  model  is  presented  in  more  abstract  terms  to 
better  describe  tin-  important  concepts.  The  following  list 
identifies  terms  in  the  model.  They  are  given  with  n  brief 
description  of  the  intended  semantics.  The  list,  also  pro¬ 
vides  a  means  to  associate  tile  abstract  terms  with  the  con¬ 
crete  terms  used  in  the  previous  sections. 


INTERNA  L_S  YSTEM 

The  INTERNAL-SYSTEM  is  H.e  system  under 
discussion.  This  is  the  system  that  is  being 
modeled.  This  section  describes  the  security 
model  of  the  INTERNAL— SYSTEM.  which 
relates  to  the  MGS  discussed  ill  the  previous  sec¬ 
tions. 

EXTERNAL-SYSTEM 

The  INTERNA  LJS  YSTEM  provides  data 
transfer  services  for  the  EXTERNA LjSYSTEMn. 
Although  security  properties  of  the 
EXTERNA L—S  1  'STEM*  are  not  being  demon¬ 
strated,  assumptions  about  these  security  pro¬ 
perties  will  be  modeled.  EXTERNA L_S YSTEMS 
relate  to  (lie  (lasts,  which  use  the  services  of  the 
MGS. 

Luiire 

The  INTER NAIS YSTEM  receives  information 
from  the  EXTERNA L— SYSTEMs  via  i_ wires, 
An  i_tnire  represents  an  incoming  connection  to 
an  END  NETWORK. 

o_ubrc 

The  INTER NAL— SYSTEM  sends  information  to 
the  EXTERNA  L—S  YSTEMs  via  w_«n>cs.  An 
o_wire  represents  an  outgoing  connection  to  an 
END  NETWORK. 

informational!  nit 

There  is  a  set  IU  of  infonnatioii.~unihi.  They  are 
used  to  carry  end-user  information  among 
i:\TERNAL_SYSTEMs  by  way  of  the 
INTERNAI.^S YSTEM.  Note  that  we  use  the 
term  iuformulion^unil  here  rather  than  Protocol 
Data  Unit  or  datagram  for  the  sake  of  generality 
and  historical  reasons.  The  two  names  refer  to 
the  same  concept . 

sec  aril yjlabe.l 

There  is  a  set  SL  of  security  Juliets.  A  single 
seeuntyjtihel  is  used  to  mark  the  Sensitivity  of 
an  iiifonnalion_nnit.  Kuril  i_irire  ( u_ivin :)  is 
associated  with  a  set  of  sec uril y_l nbcls.  An 
infonntilioi)_unil  is  accepted  for  transfer  from  at; 
i_inrc  (or  transfer  to  an  o~.tr ire)  only  if  its 
seen  nli/Jnhcl  is  an  element  of  the  set  of 
sccurityjnbel*  associated  with  the  t—ivire  (or 
,i_imic).  Note  that  it  is  not  necessary  at  this 
time  to  describe  an  inner  structure  or  com¬ 
ponents  of  a  secitnl y_l(ibel  in  order  to  deline  the 
various  functions  on  a  security Jabr.l,  or  to  define 
what  is  meant  by  the  term  SECURE  system.  A 
sec  uril  yjlabe.l  encompasses  the  notion  of  a  secu¬ 
rity  attribute  as  used  in  the  previous  sections. 

Derived J'iom 

There  is  a  notion  of  one  inform  at  ion.~unil  being 
DeniictLFrom  one  or  more  other 
information— units.  The  Derived— From  operation 
permits  the  description  of  the  security  properties 
of  fragmentation,  assembly,  transfer  from  one 
location  to  another,  encryption  and  decryption. 

Figure  2  illustrates  this  more  general  setting  and  is  to  aid 
the  understanding  of  these  terms  when  compared  with  the 
terms  used  to  describe  the  formal  model.  Again,  it  is 
important  to  note  that  the  policy  model  views  the 
INTERNAL-SYSTEM  ns  a  black  box. 
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Figure  2.  A  Pictorial  Description  of  the  Model 


Security  Assertions 

'1’lie  following  assertions  arc  to  be  satisfied  by  the  system. 
I.iy  eonininniention  we  mean  the  transfer  of 
into  rm  ation—  units. 

a.  i— wires  and  0— wires  always  connect 

SX'i  ‘ERNALS  YSTEMs  to  the  INTERNA  I, ..SYSTEM 

b.  The  only  communication  into  and  out  of  the 
INTERNAL-SYSTEM  is  via  Lwirea  and  a— wires. 

c.  All  communication  across  i-ioires  and  o-wire s  consists 
of  in/ormatioii-unils. 

d.  Each  in/onnation-unil  has  an  associated 
security-label. 

e.  Each  Lwire  and  each  O-uiire  lias  an  associated  set  of 
security-labels. 

f.  The  INTERNAL-SYSTEM  accepts  an 

information-unit  only  from  Lwire s  and  only  if  the 
securiti/Jabd  of  the  information-unit  is  an  clement  of 
the  set  of  security-labels  associated  with  the  Lwire 
bearing  the  information-unit. 

g.  The  INTERNAL-SYSTEM  delivers  an 

information-unit  only  to  O-wires  and  only  if  the 
security-label  of  the  information— unit  is  an  element  of 
the  set  of  security-labels  associated  with  the  O-Uiire  to 
which  the  infonnatwn-unil  is  delivered. 

h.  If  a  given  information-unit  is  delivered  to  an  O-Wirt. 
then  it  was  Derived-From  information-units  accepted 
from  i-wircs.  Additionally,  the  security-label  of  each 
such  accepted  information-unit  must  equal  the 
security-label  of  tile  delivered  information-unit. 

There  are  three  major  points  addressed  by  these  assertions. 
First,  there  is  an  acceptance  criterion  (Assertion  f). 
•Secondly  there  is  a  Derived-From  criterion  (Assertion  li), 
and  finally  there  is  a  delivery  criterion  (Assertion  g).  The 
other  assertions  arc  there  to  guarantee  that  the 
/ NTERN 'AL-SYSTEM  has  the  appropriate  relationship  with 
liXTEItNALjSYSTEMs.  Figure  3  illustrates  the  acceptance 
into  ,  derivation  and  delivery  out  of  the  MGS. 


Figure  3.  Acceptance,  Derivation  and  Delivery  of  the  Model 


MGS  Model  of  Policy:  Mathematical  Description 

This  section  presents  the  formal  model  of  the  security  policy 
on  Protection  Against  Compromise,  which  is  given  in  Sec¬ 
tion  2. 

The  MGS  Security  Policy  Model  is  a  structure  consisting 
of  three  components.  The  first  component,  specified  in  sec- 
tiou  1.1,  is  a  collection  of  sots.  The  second  component, 
specified  in  section  1.2,  is  a  collection  of  functions  using 
these  so  Pi.  These  functions  are  termed  “primitive”  because 
they  are  the  basis  of  all  the  security  relationships  being 
specified.  The  third  component,  specified  in  section  1.3,  is  a 
collection  of  boolean-valued  functions  which  specify  the 
necessary  relationships  among  the  various  functions.  These 
are  the  security  assertions.  Using  these  relationships  of  the 
model,  an  expression  is  then  given  that  specifies  whal  it 
means  for  a  system  to  lie  SECURE  and  based  on  the 
model. 

Throughout  this  section  the  notation  PS  (Ml  is  used  to 
denote  the  POWEK  SET  of  a  given  set  M.  For  a  set  M,  the 
power  set,  PS  ( MJ ,  is  the  set  of  all  subsets  of  t  he  set  M, 
Additionally,  for  two  arbitrary  sets,  A  and  li.  A  X  li 
denotes  the  cartesian  product  of  the  sets. 

Underlying  Sets  For  the  Policy  Model 

Let  LWIRE.  0_ WIRE.  SI..  IF  and  l)V  be  iton-emply  sets. 
Let  elements  of  these  sets  lie  called  i—  wires,  o_wire s, 
securityjabeh,  information— units  and  dala-unita,  respec¬ 
tively.  No  assumptions  are  made  about  the  sets  other  than 
that  they  are  finite  and  no  two  of  them  have  a  common  ele¬ 
ment.  Further,  let  IU  contain  two  sets,  and  Ele¬ 
ments  of  (/(/„„,)  represent  information— itniks  coming 

into  (leaving)  the  INTERNAL-SYSTEM,  respectively.  Let 
DU  contain  a  distinguished  element,  termed  the 
nulLdata_unit.  Let  INTERNAL-SYSTEM  lie  a  single 
object.  These  sets  model  the  primitive  terms  in  the  previ¬ 
ous  section  except  for  the  term  Derived-From. 

Primitive  Functions 

The  following  functions  are  the  basis  for  the  security  asser¬ 
tions  identified  in  the  policy  section.  Let  functions  he 
specified  as  follows: 
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Derived.From: 


information.unil. 

Is^aii.Of: 


Derived.From  :  IUaut  — »  PS  ( IUin )  (J) 

The  function  Derived.From  associates  with  each 
information-unit ,  in,  leaving  the  IN TER NA L_SYS TEA /,  a 
subset  of  informational  nits  that  enter.  The  Derived.F  tom 
function  can  be  used  to  discuss  the  necessary  security  pro¬ 
perties  of  fragmentation,  assembly,  transport,  encryption 
and  decryption.  This  discussion  is  illustrated  by  presenting, 
In  Section  5.2,  the  specific  relationship  between  fragmenta¬ 
tion  and  assembly  with  Derived.From. 

Is. Received'. 

Is.Rer.twed  :  /{/,,,  X  LWIRE  -*{T,F)  (2) 

The  function  Is— Received  associates  with  each 

information-unit  and  o.vnre  pair  a  boolean  value.  If 

Isjieeeived  (iu.  Lwire).  then  the  in  was  actually  received 
on  that  Lwire  by  the  INTER NA L.S 1 STEM. 

U-Delivcred-. 

D.Delwered  :  lUcul  X  O.WIRE  —  {  T  ,  F  }  (3) 

The  function  Is.Deliiv.red  associates  with  each 

information— unit  and  o.wire  pair  a  boolean  value.  If 

Is.Delioeretl  (in.  o. trite),  then  the  iu  was  actually  sent  to 
that  o.wire  by  the  INTERNA L.S YSTEA'I. 

Sensitivity: 

Sensitivity  :  IV  — ►  SI  ('!) 

The  Sensitivity  function  associates  with  each 

inforination.unit  a  sccurityjabel.  Tile  security .label  associ¬ 
ated  with  each  iu  is  used  to  control  the  acceptance  and 
delitery  of  informational  nits  on  particular  i.  wires  and 
0. wires. 

I.Wirc.A  (low: 

I.Wire.-Utuir  :  LWIRE  PS  (SL)  (5) 

The  function  l.VVire_/\llow  associates  with  each  Lwire  a 
subset,  possibly  null,  of  seciirity.labels.  An  iu  can  be 
accepted  into  the  INTERNA  L.S  YSTES  t  only  if  an 
appropriate  relationship  exists  between  the  Sensitivity  of 
the  in  and  the  sot  of  sevurily.laltels  associated  with  the 
i.wire.  The  function  LWre^/illow  allows  one  to  describe 
that  relationship,  which  is  given  by  the  function 
Is.Sec u rely^i ecepled,  and  specified  in  the  Security  Asser¬ 
tions  subsection  ('1.3). 

O.Wire^Allotv: 

O.Wire^Ulow  :  O.WIRE  —  PS  ( SL )  (G) 

Tile  function  0_Vl/ire_-ldote  associates  with  each  o_iuire  a 
subset,  possibly  null,  of  security.labels.  An  iu  can  be 
delivered  from  the  INTER NAL.SYSTEM  to  the  o.wire  only 
if  an  appropriate  relationship  exists  between  the  Sensitivity 
of  the  in  and  the  set  of  security.labels  associated  with  the 
o.unre.  The  function  O.Wire.Atlow  allows  one  to  specify 
that  relationship,  which  is  given  by  the  function 
Is.Securely^Delivered,  and  specified  in  the  Security  Asser¬ 
tions  subsection  also  (‘1.3), 

Data: 

Data  :  IU  —  DU  (7) 

The  function  Data  associates  with  each  informalio n_unit  a 
data.unit.  It  represents  the  data  portion  of  the 


IeJ>art_Of  :  DU  X  DU  —  J  T  ,  F  }  (8) 

The  function  ls_ParLOf  define  a  relation  on  data.units. 
Let  it  be  reflexive  and  transitive. 

Data_Combine: 

Data.Covibine  :  PS  (DU )  — »  DU  (0) 

The  function  Data.Combine  permits  one  to  describe  the 
bringing  together  of  data.units  into  a  single  data.unit.  Let 
tiie  image  of  the  empty  set,  (which  is  an  element  of 
PS  (DU)),  be  the  distinguished  element  of  DU,  the 
null.data.unil. 

Da  t  c_d  ceonnte  d.Fo  r: 


Data^iccountedJVor  :  IU  x  PS  [IU]  — ►  {  T  ,  F  }  (10) 

Data—/iccounied.For  is  defined  as: 

Dala.Aeeomited.For  (iu .  AT 

lff  (y) 

Tbcrc  exists  a  set  P.  P  C  DU,  such  that 
Data  (iu)  —  Data. Combine  (P)  St 

P  £  P  implies-  there  exists  tp  £  X.  Is.Part.Of  (p,  Data  (tp)  )  & 
i  £  X  implies  there  exists  p,  £  P,  Is.Part.Of  (p,,  Data  (i)  ) 

This  function  describes  wliat  it  means  for  a  given  data.unit 
to  be  related  to  other  data.units. 

Security  Assertions 

Security  assertions  identified  in  the  narrative  description 
are  expressed  in  mathematical  terms  next. 

Is.Se cutely. Accepted:  The  following  definition  specifies 
"'bal  it  means  to  be  accepted  into  tin* 
INTERNA  L.S  YSTEiU. 


Is.  Sccurcly..\e  copied  :  IV, „  X  I.WIRD  -»  {  T  ,  F  (  (12) 

Is.Sec u rely.-) ecepled  must  have  the  property: 

ls.Scniroiy.Accepted  (ill,  tr) 

W 

Seiiultnty  (iu)  £  LWire.Al/ow  (w)  St  t1"! 

Is. Received  (in,  m) 

I  lie  function  Is.Secu rety^l ecepled,  is  related  to  the 
functions  Sensitivity.  I.Wtrc.Mlow  and  Is.Rcceived.  The 
necessity  for  such  a  relationship  is  i  iiat  in  an  actual  system 
the  INTER  NA  L.S  YS  T EM  may  read  in  infohnalion.units 
from  an  Lwire  and  mav  not  be  able  to  determine  the  Sensi¬ 
tivity  of  the  particular  informal ion.umt  until  after  it  has 
been  read  in,  Once  the  Sensitivity  has  been  determined,  it 
is  then  possible  to  say  whether  it  is  permissible  tc  process  it 
further.  If  Is.Securely^lccepted  (iu.  in),  then  the  iu  is  a 
candidate  for  further  processing. 

Is.JSccuTclyJDciivtd: 

Ie.Securely  .Derived  :  lUoul  — *  {  T  ,  F  }  (14) 

Is.Secarely.Derived  must  have  the  property: 

Ii.Secdrely.Derived  flu) 

(  W  (15) 

for  every  iu 1  £  Derivcd^From  (mi) 

Sensitivity  (in)  -*  Sensitivity  (iV)  Sc 
for  some  Lwire  w,  Is^Securely^Aceepled  (iu1,  w)  Sc 
Data^Aecounted^For  (iu,  Dtrived^From  (iu)  ) 

The  function  I$_Securely-Derived  is  related  to  other 
functions.  This  relationship  is  specified  in  expression  (16). 
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Specifically,  a  given  information— unit  is  determined  to  be 
securely  derived  if  and  only  if  three  conditions  are  satisfied. 
First,  the  particular  infonnalion_unit  was  Derived— From  a 
set  o.'  information— units  that  they  themselves  were  securely 
accepted.  Second,  each  of  these  securely  accepted 
information— units  have  the  same  Sensitivity  as  the  derived 
infonnoliun-vnt.  Third,  the  data  portion  of  derived 
h  formation. unit  equals  the  combination  of  data_unils  that 
are  themselves  part  of  the  data  of  the  incoming 
information-units.  Note  that  the  Sensitivity  of  the  derived 
iu  is  the  same  as  the  Sensitivity  of  the  accepted  ius.  If  an 
information— unit  is  determined  to  be  securely  derived,  then 
it  is  a  candidate  for  further  processing. 

IsSt: c u rchj—DcIive re d:  The  next  definition  specifies  the 
conditions  that  must  lie  met  before  an  information— unit  can 
be  placed  on  a  particular  O-it'irc. 

Li_Sci' \n  tiy_Dclivtrcd :  tO0ui  X  0._  WIRE  — -  {  T  ,  F  }  (16) 

IsSec urely— Delivered  must  have  the  property: 

h-Sccurclti-Delivcrt d  (in.  nri 

iff  (17) 

Sensitivity  (rn|£  0_\\firc—Uluiv  (tv)  &) 
h^Scruitty_!)crii'C<!  (i»r)  J 

The  function  Is— Securely-Delivered  is  a  boolean  function. 
Just  as  there  is  a  specific  relationship  between  the  function 
IsSec it rely— A cc opted  and  some  other  functions,  there  is  to 
he  a  specific  relationship  with  the  function 
IsSev  urely— Delivered  and  additional  functions.  Expression 
(17)  gives  that  relationship.  Specifically,  a  particular 
information— unit  is  said  to  be  securely  delivered  if  and  only 
if  two  conditions  are  satisfied.  First,  the  set  of 
security-labels  associated  with  that  particular  o—wire  must 
have  ns  an  element,  the  security-label  of  the  particular 
delivered  informational! nit.  Second,  the  information— unit 
must  have  been  securely  derived.  These  are  the  conditions 
specifying  what  it  means  to  deliver  an  informational  nit  to  a 
given  u-wire  securely. 

Definition  of  a  Sc cu>e  System 

The  definition  of  a  secure  system  is  given  in  this  subsection. 
Ah  presented,  the  MCiS  Security  Policy  Model  is  a  slructurc 
consisting  of  three  components.  Even  though  it  allows  for 
considerable  flexibility,  it  is  intended  that  the  meaning  of 
security  be  the  same  no  matter  how  one  may  choose  to  use 
the  flexibility  provided.  The  flexibility  is  allowed  bv  letting 
the  actual  choice  of  the  sets  (first  component)  and  the  func¬ 
tions  defined  using  them  (second  and  third  ,  .miponent.s)  be 
left  to  a  given  design  and  implementation  approach. 

In  order  to  accurately  describe  what  it  means  for  a  sys¬ 
tem  to  be  Secure  based  on  the  model,  two  additional 
notions  need  to  be  described.  First,  definitions  of  what  an 
instance  of  the  model  is  and  what  security  means  within 
that  particular  instance  of  the  model  need  to  be  identified. 
Second,  a  means  of  relating  a  system  to  a  particular 
instance  of  the  model  needs  to  be  identified. 

An  INST  A  NCE—  OF—M  ODEL  is  defined  to  be  a  particu¬ 
lar  choice  for  each  of  the  live  sets  and  a  particular  choice  of 
the  primitive  functions,  e.g„  Derived-From.  Is_l{eceived. 
ls_Delivtred,  Sensitivity.  /_ Wire— A llv w,  etc.  that  satisfy  the 
specified  expressions  (1)-(17). 

Note  that.  the  functions,  luSecurcly— Accepted, 
IsSecurehj— Derived  and  Is-Securety-Delivcrcd.  are  defined 
in  terms  of  the  previous  functions  and  n„  arbitrary  choice 
can  he  made  for  them. 


An  INSTANCE— OF-MODEL  is  defined  to  lie  SECURE 
if.  for  the  corresponding  choices  made  in  determining  the 
particular  INST  A  NCE— OF. — M  ODEL,  tin*  following 
statement  is  true: 

for  every  iu  £  IU 
if 

Is— Delivered  (iu,  w )  (18) 

then 

Is— Securely— Delivered  (iu,  w) 

Note  that  the  expression  in  (18)  is  the  only  place  where 
the  function  Is— Delivered  is  related  to  the  function 
is— Securely— Delivered. 

Consider  an  arbitrary  system  and  a  given  instance  of 
the  model,  denoted  by  INSTANCE— OF— MODEL.  An  asso¬ 
ciation  of  the  INSTANCE-OF-MODEL  to  the  entities  of 
the  system  is  defined  to  be  a  mapping  from  the  particular 
components  of  INSTANCE-OEJi'lODEL  to  the  system’s 
entities. 

A  system  is  said  to  he  SECURE  and  Based  on  the 
Model  if  the  following  conditions  are  satisfied.  First,  there 
exists  an  instance  of  the  model,  iNS'l'ANCE— OF— MODEL. 
Second,  there  exists  an  association  of  the  instance  of  the 
model,  1 NSTA NCE- OF-MODEL,  to  the  system’s  entities, 
Third,  suppose  1  e  system  actually  delivers  an  entity  that 
corresponds  to  an  iiiformalioii-imit  under  the  particular 
association  and  model  instance.  Then  the  expression  num¬ 
bered  (18),  when  interpreted  within  the  system  via  I  lie  same 
association,  is  to  evaluate  to  true  if  and  only  if  the  expres¬ 
sion  (18)  within  INSTANCE— OF— MODEL  evaluates  to  true, 

MGS  Model  of  I’olicy:  Discussion 

The  policy  stated  as  the  M(iS  .Security  Policy  in  Section  t! 
and  the  associated  formal  model  given  in  Section  •!  are  very 
general.  Depending  on  given  instances  of  the  inidel,  includ¬ 
ing  the  definition  of  security— lubebi  and  the  nssoeinlion  ol 
security-labels  with  the  ports  of  a  system,  all  soils  ,,f  ||im-s 
are  possible.  To  enforce  Dol)  policy,  one  experts  to  use  the 
Doll  security  labeling  scheme.  One  expects  to  not  permit 
tiie  write  down  of  information;  that  is,  labeling  a  port  with 
a  high  label  when  all  the  EX'l'ERNAL-SYSTEMs  eonneeird 
to  it  are  at  low  level.  The  associated  wires  should  not  lie 
permitted  to  carry  the  high  data,  The  model,  in  fart,  disal¬ 
lows  this.  This  is  one  of  I  lie  places  where  (lie  administra¬ 
tive  actions  in  determining  the  security— labels  associated 
with  ports  becomes  crucial  to  enforcing  Dol)  policy. 

Specific  observations  about  the  formal  model  and  the 
type  of  policies  one  can  obtain  from  the  model  are 
summarized  below. 

Observations  On  the  Formal  Rolicy  Model 

There  is  neither  a  “destination"  nor  “source"  function 
defined  on  the  set  of  information  units.  While  il  is  tempt¬ 
ing  to  introduce  such  concepts,  it  is  not  necessary  for  this 
particular  environment,  and  would  probably  impose  addi¬ 
tional  diilicultics  for  the  formal  verification  of  n  system 
based  on  such  a  model.  Additionally,  the  formal  model  does 
not  explicitly  incorporate  (at  this  time) 
non— information— units  although  the  security  policy  does 
identify  such  entities.  The  focus  of  the  formal  modeling  has 
been  on  handling  end-user  information  rather  than  oi: 
modeling,  for  example,  protocol  control  messages.  Such 
information  would  not  have  the  same  acceptance  or  delivery 
checks.  Furl  In  r.  such  lion  end-user  information  leaving  the 
system  needs  to  be  "derived  from"  only  mm  end-user  and 
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system  initialization  information  and  not  be  mixed  with 
end-user  information. 

Note  that  the  empty  set  (or  null  label)  can  not  be  asso¬ 
ciated  with  ail  information  unit.  A  particular  is’ire  or 
osvirc,  however,  may  have  the  empty  set  associated  with  it 
(via  the  functions  I— Wire— /[Ro  to  and  O—Wire—Alloio).  If  it  is 
an  i—wne,  then  no  informal ion— units  will  be  accepted  from 
that  isdre.  If  it  is  an  os'ire,  no  informal ion— units  will  be 
delivered  to  it. 

There  is  nothing  in  the  assertions  that  guarantees  the 
delivery  of  informations  nils  once  they  are  accepted  into 
the  system.  It  may  turn  out  that  all  security-label  sets 
ussoeinted  with  os’ire s  do  not  contain  the  security-label  of 
an  accepted  informal tonsnit. 

If  an  informalionsnit  was  delivered  from  the 
INTERNA  LS  YSTEM,  then  there  was  at  least  one 
informutionsnit  accepted  into  the  INTER  NA I,_S YSTEM. 
The  information  contained  in  the  delivered  iu  was 
Derived-From  the  accepted  informal ioh_ii/ii7(s). 

There  is  no  connection  ill  the  model  between  an  i sire 
and  an  o_it'tn'.  In  a  particular  application,  eaeli  is’ire  may 
lie  paired  willi  an  O-tvire.  lint  the  security— label  sets 
allnehfd  to  the  /_ir;rcs  and  O-ivircs  are  indt  pendent  of  each 
oilier,  lienee  in  an  i_wirc  /  osdre  pair,  the  i-irire  and 
o_irirc  may  have  ilillcrcnt  secitritij-luhel  sets  associated  with 
them.  Also,  an  IN V 'Ell NA LS ) >'7 'Eh l  can  securely  deliver 
an  in  to  more  limn  one  os’ire. 

An  EXTERNA LS) 'STEM  may  he  connected  to  the 
INTERNA LSYSTEM  hy  n  single  is’irc  or  o_««ic.  That  is, 

1  lie  EXTERNAL'S)  STEM  may  he  only  a  source  or  a  sink 
for  information  with  respect  to  the  INTERNAL-SYSTEM. 

Furl  her.  the  data  will  not  necessarily  stay  constant 
l hronghmit  its  traversal  of  an  INTERNAL— SYSTEM.  In 
fact,  ii  may  change  because  of  fragmentation,  encryption, 
decrypt  ion,  etc,  l  'onsecpieiit  ly.  I  here  is  no  reason  to  expect 
nny  verification  regarding  the  possibility  of  no  change  to 
I  lie  data  or  some  portion  of  t  lie  data. 

'flic  security  policy  and  formal  model  allow  transforma¬ 
tions  on  iiiforiiinlion  units  that  relate,  under  a  given  condi¬ 
tion.  two  or  more  units  to  another  single  information  unit 
(refer  to  policy  statement  (h)  of  Protection  Against 
Compromise  and  I  he  notion  of  derivation).  This  may  poten¬ 
tially  permit  dnta  aggregation,  where,  hy' the  model  scheme, 
a  resulting  information  unit  would  have  a  sensitivity  label 
possibly  lowin'  Ilian  the  aggregation  of  the  set.  of  associated 
information  units.  Thee  art*  two  aspects  to  this  aggrega¬ 
tion.  Pitst ,  the  aggregation  is  achieved  “outside”  the  sys¬ 
tem.  Namely,  the  system  being  modeled  is  n  datagram  ser¬ 
vice  ami  the  aggregation  would  be  related  to  the  higher 
level  transport  services  using  the  datagram  service  of  the 
system  being  modeled.  Second,  if,  within  tile  modeled  sys¬ 
tem,  one  assembles  information  units,  they  are  assembled 
from  a  related  entity  that  was  previously  fragmented.  The 
assembly  is  actually  the  re- assembly  of  a  previously  frag¬ 
mented  datagram.  Therefore,  in  this  second  ease  there 
would  be  no  aggregation. 

Finally,  the  concept  of  Derived— Erom  is  distinct  from  the 
concept  of  Data  and  I  lie  combination  of  data.  The  latter  is 
i  lit  roiliircil  to  describe  the  necessary  properties  of  fragmen¬ 
tation  mid  assembly.  The  concepts  are  brought  together 
only  in  I  lie  meaning  of  ts_Se rurely_De rtv r. d. 

Assembly,  Fragmentation  and  DeriuedS'rotn 

This  subsection  shows  how  the  function  Derived— From 


models  both  assembly  ami  fragmentation.  The  upper  por¬ 
tion  of  Figure  '1  illustrates  the  concept  of  the  assembly  and 
fragmentation  of  information— units  across  the 
INTER  NA  LS  YS  TEM. 

Now  consider  the  function  Derived-From.  As  defined, 
the  image  of  an  information-unit  under  Derived— From  is  a 
set  of  incoming  information-units.  Observe  that  the  sense 
of  direction  of  the  function.  Dr rived_Erom,  considers  an 
outgoing  information— unit  and  “looks  hack”  at  what  the 
given  information— unit  is  derived  from  among  the  incoming 
information— units  (refer  to  lower  portion  of  Figure  4).  In 
this  way  assembly  is  represented  directly  by  the  function 
Derived-From. 

To  explicitly  relate  fragmentation  to  Derived— From,  one 
additional  definition  is  needed.  For  a  given 
information— unit,  iu  belonging  to  HJiH,  define  the  following 
set: 


FRAGMENTS  (in)  =(/|  /  £  /l  in  £  Perived-I'rom  (/) } 

'l'lie  set,  FRAGMENTS  (iu],  identifies  all  those  outgoing 
information— units  that  arc  related  to  the  given  iu  by  the 
function  Derived— From.  In  this  way,  fragmentation  is 
modeled  by  the  function  Derived— From. 

Two  properties  are  associated  with  Derioed—From  (ref: 
expression  lf>  of  Section  d).  They  are  the  security  proper¬ 
ties  for  fragmentation  as  well  ns  assembly.  First,  for  a 
given  outgoing  informations  nit.  iu, 


For  all  i  £  Derived-From  (ill).  Sensitivity  (m)  =  Sensitivity  (r) 


Second,  all  portions  of  data  in  iu  are  to  he  accounted  for  hy 
data  in  the  information-units  of  the  set,  Dcriued-From  (iu). 
This  concept  is  capt  ured  by  Data— Accounted— For  of  Section 


FRAGMENTATION 


iu 


in 


IU 


out, 


Dvrl  From  Cl  u ) 


Figure  4.  Assembly,  Fragmentation  and  Derivod_From 

An  incoming  information-unit  that  does  not  leave  the 
INTERNAL— SYSTEM  is  modeled  by  Derived-From  by  hav¬ 
ing  t  hat  incoming  information-unit  not  be  an  element  of  the 
image  of  any  outgoing  information-unit  under 
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fragmentation  are  adequately  modeled  as  described,  then 
the  approach  is  symmetric.  Specifically,  referring  to  the 
lower  portion  of  Figure  4  and  “looking  forward,"  rather 
than  “backward,"  one  could  define  a  function 
"Derive _For.”  which  would  associate  a  set  of  outgoing 
in fo rmatio n_ u n its  with  an  incoming  informal ion— unit.  Frag¬ 
mentation  and  assembly  would  be  modeled  in  an  analogous 
manner.  Since  we  arc  interested  in  what  goes  out  of  a  sys¬ 
tem  based  on  what  comes  into  it,  the  choice  was  made  as 
given. 

Security  Assertions  as  Mathematical  Relationships 

Certain  assertions  within  the  policy  are  represented  within 
the  formal  model  as  specific  relationships  among  functions. 
Specifically,  one  can  think  of  the  INTER  N A LS VS TEM  as 
a  device  that  reads  information-anils  from  i-iuircs,  produces 
new  i>ifonnation_iinits  from  the  accepted  ones,  and  delivers 
information— units  to  o-wircs. 

The  security  assertions  (a)-(c)  of  subsection  3.2  above 
must  actually  be  satisfied  by  both  physical  and  hardware 
limitations  of  the  INTER NAI.S ) 'STEM.  It  is  assumed  that 
the  INTE11NA L-S YSTEM  is  connected  only  to  packet 
switch  networks.  It-  is  assumed  that  all  input  and  output  of 
infori.ialiii»_imits  to  the  INTER  NAL— SYSTEM  occur 
through  only  these  networks.  It  is  assumed  that-  these  net¬ 
works  are  connected  only  to  external 
INTER  NAL-SYSTEMs  and  in  fact  tli.it  the 

in  for  in  a  t  ion _ it  n  its  transferred  to  the  INTERNA  l,S  1  STEt\  I 

have  security-labels.  That  is.  that  it  is  possible  for  the 
INTERNAL-SYSTEM  to  determine  the  security-label  of  all 
informal ioii.uiiits  received. 

The  collection  of  functions.  DeriveiLI'rom.  Is-Rcceivcd. 
Is-Delive red,  Sensitivity,  l-\\'ire—\llou‘.  and  O— Wire— Allow. 
are  primarily  for  description.  They  either  describe  proper¬ 
ties  of  the  information-units  or  of  the  i-U'irea  and  o-wires. 

The  last  three  security  assertions  stated  in  section  3.2 
arc  described  mathematically  in  sections  4.3. 1-1. 3.3.  At  any 
instant  of  time,  the  INTER NALSYSTEM  must  lie  secure 
in  llie  sense  of  the  definition  in  1.1.  That  is.  nil 
information-twite  actually  sent  to  an  o_ wire  up  to  that 
point  must  satisfy  the  conditions  given  in  1,1. 

Implementing  a  System-Specific  Security  Policy 

To  implement  a  particular  security  policy  within  a  system 
based  on  the  model,  several  steps  are  required, 
a.  Determine  t he  set  of  security-labels. 

1).  Determine  the  set  of  information-units  to  lie  managed 
by  t lie  INTERNAL-SYSTEM.  This  set  will  change 
with  time. 

c.  Determine  the  mechanism(s)  in  the 
INTERNAL-SYSTEM  for  determining  the  Sensitivity 
of  information— units. 

d.  There  must  be  databases,  or  some  other  mechanisms, 

in  the  INTERNAL-SYSTEM  so  that  the  functions 
1—  Wire— .Allow  and  O-Wirt-Allow  can  be  implemented. 
These  databases  must  be  securely  initialized  and  pro¬ 
tected  from  unauthorized  changes.  The  content  of 
these  databases  determines  the  acceptable  flow  of 
information— units  from  i..wires,  through  the 

INTERNAL-SYSTEM,  and  finally  to  O-unres.  Various 
specific  policies  can  be  ini  'lamented  depending  on  the 
content  of  the  databases. 

e.  Tlie  INTERNAL-SYSTEM  must  have  a  notion  of 
.Derived— prom,  which  has  the  identified  properties. 


f,  It  must  then  be  verified  that  the  system  maintains  the 
definition  of  SECURE  for  every  information— unit 
actually  sent  out  on  an  O-wire. 

The  model  supports  a  number  of  specific  security  poli¬ 
cies.  The  security  policy  in  force  for  a  particular  implemen¬ 
tation  of  the  model  depends  on  the  security— label  set  and 
the  distribution  of  the  subsets  of  security-labels  to  the  vari¬ 
ous  i-ivires  and  0— wires.  Fur  example,  Dol)  policy  would  be 
that  if  an  i-tuire  or  o_wire  could  carry  top  secret  informa¬ 
tion.  it  could  also  carry  secret,  confidential  ami  unclassified 
information,  unless  explicitly  staled  otherwise.  This  can  be 
modeled  by  having  the  security— label  set  of  the  i_wire  or 
O-U'ire  contain  all  four  classdications.  This  allows  the  tie  to 
the  familiar  “dominance"  relation  identified  in  [l|. 

Another  policy  might  be  that  the  i-wire  or  o-wirc  con¬ 
nected  to  EXTERNAL— SYSTEMs  should  only  allow  secret 
information.  This  can  be  described  in  the  model  by  having 
the  security— label  set  associated  with  the  i_inirc  and  o-wire 
Hint  connect  the  EXTERNAL-SYSTEM s  to  the 
INTERNAL— SYSTEM  to  contain  only  the  element  secret. 
Informal ion— units  with  other  than  a  secret  security-label 
cannot  then  lie  carried  on  the  purticulnr  i-tuire.  Other 
specific  policies  can  he  realized  via  this  general  policy 
model. 

Model  Validations 

it  is  often  required  to  validate  a  given  model  in  two  ways. 
First,  validate  that  the  model  actually  represents  the*  con¬ 
cepts  and  statements  within  a  given  security  policy.  Call 
this  an  external  validation.  For  the  Mnltinet  Clateway  Sys¬ 
tem,  tills  external  validation  is  based  on  the  Protection 
Against  Compromise  Policy.  Second,  validate,  by  some  rea¬ 
sonable  means,  that  the  model  is  consistent  within  itself. 
Call  this  an  internal  validation.  Doth  validations  of  the  for¬ 
mal  model  are  gi"en  in  [!)),  The  internal  validation  gives 
our  interpretation  of  the  requirement  staling  ",  .  ,  a  formal 
model  of  the  security  policy  supported  by  t  he  TCB  shall  be 
maintained  .  .  .  I  lint  is  proven  consistent  with  its  axioms  (1, 
para .  d. 1.3.2.:>|." 

Conclusions 

This  paper  has  presented  an  internet  security  policy  and 
formal  security  policy  model.  The  scope  of  the  security  pol¬ 
icy  is  the  collection  of  the  security  properties  of  a  packet- 
switched  internet  system  providing  it  datagram  service. 
The  formal  model  focuses  on  protection  against  comprom¬ 
ise.  The  paper  has  summarized  the  approach  taken  to 
show  informally  that  the  model  is  a  representation  or  an 
appropriate  portion  of  the  policy  and  that  the  model  itself 
has  an  internal  consistency.  It  illustrates  a  way  of  model¬ 
ing  the  security  attributes  of  an  internet  system  and  pro¬ 
vides  a  specific  example  of  one  such  security  model.  The 
model  and  approach  outlined  here  has  been  used  in  the  pro¬ 
duction  of  the  formal  specification,  in  Gypsy,  of  the  Mul- 
tiuet  Gateway  System,  and  in  the  formal  verification  of 
that  specification. 

The  authors  gratefully  acknowledge  the  careful  review 
provided  by  Jim  Williams,  Don  Good,  Mike  Smith  and  Max 
Heckard  of  previous  drafts  during  the  development  of  this 
papei . 
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Abstract 

This  paper  presents  an  overview  of  the  Ulysses  com¬ 
puter  security  modeling  environment.  Ulysses  is  a  design 
environment  in  which  models  of  systems  can  be  described 
formally,  properties  of  those  models  can  be  verified,  and 
in  which  specialized  security  analysis  is  supported  by  a  for¬ 
mal  theory  of  security.  The  theory  of  security  is  motivated 
by  non-deducibility  and  non-interference  concerns,  and  it 
also  permits  the  security  analysis  of  complex  designs  by 
decomposing  them  into  interacting  parts.  Graphical  and 
textual  specification  languages  allow  users  to  describe  these 
design  decompositions  in  an  intuitive  manner,  while  remain¬ 
ing  grounded  in  the  formal  theory  of  security,  A  natural- 
language  component  generates  English  descriptions  of  user- 
created  models.  A  library  facility  allows  re-use  of  secure 
models.  The  use  of  this  environment  requires  extensive 
theorem-proving  and  heuristic  support;  this  is  provided  by  a 
powerful  mathematical  engine,  incorporating  a  meta-language 
facility. 

1  Introduction 

Ulysses  is  a  collection  of  tools  that  assist  in  the  design  and  ver¬ 
ification  of  secure  computer  systems.  It  is  being  developed  at 
Odyssey  Research  Associates  (ORA)  in  Ithaca,  New  York,  It 
provides  a  rich  environment  in  which  botli  new  and  previously 
defined  secure  systems  and  secure  system  components  can  be  dy¬ 
namically  examined  and  incorporated  into  a  system  design.  The 
design  methodology  supported  by  Ulysses  uses  the  same  princi¬ 
ples  of  modularity  and  reusability  that  characterize  modern  pro¬ 
gramming  development  environments.  Because  Uiysses  supports 
tire  verification  of  security  properties,  it  includes  an  automated 
theorem  proving  engine  and  tooL  for  constructing  proofs.  This 
paper  is  intended  to  give  an  overview  of  the  important  idea?  and 
tools  incorporated  by  the  system. 


From  a  security  standpoint,  the  most  important  feature  of  Ulysses 
is  the  capability  of  producing  a  complete  and  formal  proof  of  se¬ 
curity.  A  security  methodology  is  a  definition  of  security  together 
with  a  collection  of  theorems  which  aid  in  constructing  a  proof 
of  security  for  particular  models.  These  theorems  are  often  ex¬ 
pressed  as  conditions  for  deducing  the  security  of  a  whole  system 
from  the  properties  of  its  components.  With  such  a  methodol¬ 
ogy,  the  task  of  proving  security  of  an  entire  system  reduces  to 
the  smaller  tasks  of  showing  the  particular  properties  on  only 
parts  of  the  system.  When  a  methodology  car.  be  carried  out 
formally  we  say  that  it  is  the  basis  for  a  formal  security  analysis. 
One  instance  of  such  a  security  methodology  is  the  noninterfer¬ 
ence  security  definition  and  theory  of  [McCSSb],  In  this  case, 
whenever  all  of  the  components  are  shown  to  be  secure  then  one 
can  conclude  the  system  is  also  secure.  This  sort  of  property  is 
called  rornposable  or  a  “hook-up”  property.  Composable  proper¬ 
ties  are  particularly  easy  to  work  with.  The  more  general  security 
methodologies  arc  often  constructed  to  be  applied  to  particular 
classes  of  models  (e.g.  a  process  connected  to  a  buffer).  The 
Ulysses  environment  is  one  which  aids  in  both  the  development 
and  the  formal  application  of  security  methodologies. 

As  a  design  tool,  Uiysses  was  influenced  by  the  experience  of 
the  MASCOT  project  [StaSGj  and  the  hierarchical  design  ab¬ 
straction  of  Moriconi’s  PegaSys  system  (MUSS).  These  pictorial 
system  description  schemes  arc  similar  to  the  graphical  specifica¬ 
tion  tauguage  that  Ulysses  users  will  be  given  to  describe  systems. 
The  design  process,  which  Moriconi  calls  refinement,  is  primar¬ 
ily  “top-down".  A  user  begins  with  a  diagram  representing  the 
entire  system,  and  refines  it  by  dividing  it  into  sub-systems,  each 
represented  by  an  icon.  Connections  between  sub-systems  are 
also  specified  as  icons.  The  meaning  of  each  icon  is  given  for¬ 
mally  in  tlie  theory  of  security,  and  the  user  may  also  associate 
other  information  (documentation,  other  formal  specifications) 
with  the  icons.  The  design  is  “grounded”  by  associating  formal 
textual  specifications  in  the  theory  of  security  with  atomic  icons 


-This  work  was  supported  by  lli<-  Air  Force  Systems  Command  ■■  t  Koine  Air  Development  Center  under 
Contract  No.  F30CO‘Z-85-C-0098.  Tin1  views  and  conclusions  couiniiie,!  in  ibis  paper  are  those  of  the  authors 
and  should  not  be  interpreted  ns  necessarily  representing  ilie  ollicinl  policies,  either  expressed  or  implied,  of 
the  Air  Force  or  the  U.S.  Government 
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(i.e.,  icons  representing  components  that  have  not  been  further 
graphically  refined).  If  each  atomic  component  is  proved  secure 
(in  the  sense  of  (McCS7j),  then  the  “hoolt-up  theorem”  can  be 
used  to  infer  the  security  of  the  entire  system. 

One  of  the  more  innovative  aspects  of  the  Ulysses  system  is  its 
mathematical  foundation.  Ulysses  is  being  developed  in  a  formal 
system  based  on  a  constructive  type  theory  which  is  also  capa¬ 
ble  of  expressing  classica.  mathematics.  The  advantages  of  this 
foundation  fall  under  two  heads — improved  support  for  security 
modeling  and  exciting  prospects  for  future  extensions. 

Security  modeling  support  is  enhanced  because  the  logical  basis 
allows  for  a  more  rigorous  treatment  of  modeling  than  previous 
bases.  This  enhancement  has  two  main  aspects.  First,  for  many 
security  theories,  it  is  possible  to  formalize  the  relation  between 
the  theory  and  the  semantics  of  the  specification  language  used 
to  describe  systems.  Second,  the  economy  with  which  the  under¬ 
lying  logic  is  formulated  and  its  known  consistency  allay  doubts 
about  correctness  of  the  implementation  and  about  correctness 
of  the  logic  itself. 

The  logic  also  allows  the  modeling  of  polymorphic  typing,  which 
is  of  great  interest  in  current  discussion  of  programming  lan¬ 
guages,  and,  due  to  its  constructive  character,  includes  a  pow¬ 
erful  model  of  computation.  We  believe  that  these  features  will 
make  it  possible  to  extend  Ulysses  to  include  a  system  develop¬ 
ment  environment  which  is  both  sound  and  robust. 

The  paper  is  organized  as  follows.  Section  2  explains  in  greater 
detail  the  primary  theory  of  security  being  used  ill  Ulysses.  Next, 
in  section  3,  various  ways  in  which  the  system  can  be  used  arc 
described.  Tilt  implementation  of  the  type  theory  mentioned 
above  is  discussed  in  section  ■!.  Finally,  in  section  5,  we  conclude 
with  a  few  remarks  about  the  software  implementation  of  Ulysses. 

2  Security  Aralysis 

Secure  design  in  Ulysses  depends  on  flexible  and  sound  theoreti¬ 
cal  foundations.  To  develop  such  foundations  we  examined  pre¬ 
vious  formalisms  for  security,  particularly  the  pioneering  work  of 
Bell  and  LaPadula  in  access  control(BL7C],  the  non-interference 
model  of  Cioguen  and  Meseguer(GM82j,  and  the  informal  ion  flow 
theory  of  Sutherland  [SutSO]. 

Our  investigations  convinced  us  that  these  previous  models  of 
security  were,  for  the  purposes  of  secure  design  in  Ulysses,  lacking 
in  some  respects.  Some  of  the  problems  we  found  among  these 
formalisms  were 

o  they  were  not  based  on  observable  behavior 
o  they  were  not  sufficiently  implementation-independent 
o  they  could  only  be  applied  to  completed  systems,  and  there¬ 
fore  could  not  be  used  for  the  incremental  development  of 
a  secure  design 

o  they  only  applied  at  one  level  of  abstraction 
o  they  were  only  suitable  for  deterministic  systems 

The  biggest  problem,  however,  was  that  there  was  no  research  on 
the  interactions  of  trusted  systems  and  processes — in  particular, 
it  was  not  known  to  what  extent  security  was  preserved  when 
one  connected  several  trusted  systems  into  a  distributed  system. 


The  primary  security  formalism  used  by  Ulysses  is  based  on  this 
previous  work,  but  it  goes  beyond  it  in  that  it  is  intended  to 
be  useful  in  design  as  well  as  in  implementation.  In  contrast 
with  the  proceeding  formalisms,  the  Ulysses  security  formalism 
can  be  used  to  analyze  the  security  of  isolated  components  and 
partially  fleshed-out  system  designs,  whose  implementations  are 
still  undetermined.  This  gives  the  designer  greater  flexibility, 
allowing  him  to 

o  reuse  off-the-shelf  secure  components 

o  discover  the  security  flaws  of  a  design  early  so  as  to  mini¬ 
mize  wasted  effort 

o  freely  substitute  components  with  equivalent  security  char¬ 
acteristics 

A  formal  definition  of  secure  processes  that  had  many  of  the  de¬ 
sirable  features  mentioned  above  has  been  developed  by  McCul¬ 
lough  ([McC88b]).  One  of  the  properties  derivable  from  this  the¬ 
ory  is  the  “hook-up”  property,  whiclr  provides  the  basis  for  a  for¬ 
mal  security  analysis.  The  theory  is  formulated  in  terms  of  state- 
machines.  Each  state  transition  corresponds  to  a  possible  input, 
output  or  internal  event  of  a  system.  Non- deterministic  choice 
between  different  transitions  is  allowed.  Within  this  framework, 
a  security  properly  can  be  defined.  We  call  this  property  ‘flow 
security’.  It  is  a  noninterference  property  which  limits  the  effect 
tiiat  transitions  associated  with  high  security  levels  can  have  on 
transitions  at  lower  security  levels.  These  limits  formalize  the 
intuitive  notion  that  information  should  not  flow  from  high  level 
users  to  low  level  users.  It  is  a  composab.e  property,  meaning 
that  if  system  A  and  system  B  are  each  flow-secure,  then  the 
combined  system  of  A  composed  with  B  will  also  be.  It  must 
be  noted  that  other  security  properties  often  turn  out  not  to  be 
composable  (McCSSa). 

Using  Ulysses  to  prove  that  components  are  flow-secure  will  per¬ 
mit  us  to  incrementally  verify  the  security  of  a  system.  Once 
the  flow-security  of  all  atomic  components  is  verified,  the  flow- 
security  of  the  entire  system  is  assured. 

Although  a  particular  theory  of  processes  and  a  particulai  theory 
of  security  are  used  in  Ulysses,  they  are  neither  fixed  nor  “built 
in".  The  theory  of  security  may  be  expanded  by  proving  (within 
Ulysses)  new  facts  about  the  hook-up  of  processes.  For  example, 
tile  hook-up  of  several  processes,  none  of  which  is  secure,  may 
form  a  combined  process  that  is  secure  (WLS7|.  Ulysses  allows 
tlie  formulation  of  such  new  theories  of  security.  These  alternate 
theories  could  then  be  used  in  proving  new  hook-up  theorems 
as  well  as  properties  of  systems.  The  mechanisms  for  packaging 
new  theories  and  referencing  them  are  outlined  in  section  4. 

3  How  Ulysses  Will  Be  Used 

The  user  may  interact  with  the  system  through  several  specially 
designed  interfaces.  They  are: 

o  The  graphical  system  design  interface:  graphical  system 
descriptions,  in  which  icons  have  formal  meaning  in  the 
theory  of  security,  are  used  to  describe  the  design  of  a  model 
from  its  secure  components 

o  The  natural  language  component:  brief  summaries  of  the 
design  and  its  security  characteristics  may  he  generated 
automatically 
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o  The  verification  and  textual  specification  interface:  textual 
specifications  of  components  can  be  built  and  verified,  new 
security  theories  can  be  added  to  the  system,  and  tactics 
(heuristics)  for  proving  security  can  be  built 
o  The  library  browsing  interface:  models  and  other  informa¬ 
tion  stored  in  the  Ulysses  system  may  be  reviewed  and 
updated 

In  tile  next  few  sections  we  provide  a  more  detailed  description 
of  these  interfaces. 


3.1  Operations 

User  interactions  fall  into  three  main  divisions:  adding  informa¬ 
tion  to  the  system,  retrieving  information  from  the  system  and 
deriving  new  information  w  ithin  the  system.  The  subject  of  most 
end  user  interactions  will  be  descriptions  of  computer  systems. 
These  are  most  naturally  presented  in  a  graphical  manner,  al¬ 
lowing  the  user  to  visualize  the  subject  system.  The  graphic  lan¬ 
guage  employed  presents  objects  hierarchically,  much  like  the  Pe- 
gaSys  system[MHd5].  Within  this  context  of  graphical  represen¬ 
tations  the  following  operations  are  typical  of  what  the  Ulysses 
user  interface  supports: 

o  Retrieving  Information: 

-  view  an  archived  system  or  component 

-  show  (or  hide)  the  sub-components  of  an  'con  repre¬ 
senting  a  process 

-  show  the  textual  specification  associated  with  an  icon 

-  show  the  textual  specification  associated  with  tile  hook¬ 
up  of  two  icons 

o  Adding  Information: 

-  load  an  archived  component  into  the  current  system 
design 

-  create  (or  delete)  a  hook  up  (i.e.,  a  communication 
channel)  between  two  processes 

-  refine  an  icon  representing  a  system  by  adding  or  chang¬ 
ing  icons  representing  its  sub-components 

-  associate  formal  textual  specifications  and  other  prop¬ 
erties  with  an  icon 

o  Synthesizing  Information: 

-  prove  that  component  specifications  imply  the  speci¬ 
fications  oi  tlio  systems  they  form 

-  give  general  mathematical  facts  to  assist  in  proving 

security 

-  ask  tlie  system  to  assist  heuristically  in  developing  a 
secure  system 

Some  of  these  operations  involve  interfaces  besides  the  strictly 
pictorial  or  graphical  one  suggested  above.  For  example,  the 
natural  language  interface  produces  English  text  as:,-  dated  witli 
graphical  displays  of  the  system.  Textual  specifications  for  atomic 
icons  are  produced  by  interacting  with  an  editor.  Retrieving 
archived  systems  may  involve  browsing  through  the  library  of 
stored  specifications.  Generating  proofs  involves  using  tire  inter¬ 
face  to  the  theorem-prover  and  its  tactics  (heuristics). 


3.2  The  Graphics  Interface  -  An  Example 

The  Ulysses  graphical  design  environment  allows  the  designer  to 
select  an  icon  representing  a  component,  (usitig  a  mouse-driven 
“point-and-clidc"  scheme),  and  cause  Ulysses  to  open  up  the 
component  so  that  its  internal  structure  can  be  seen.  The  com¬ 
ponents  can  themselves  be  made  up  of  lower-level  components. 
The  lowest  level  may  either  be  left  pending  or  contain  a  link  to 
a  textual  process  specification. 

We  describe  the  way  the  graph.es  system  works  by  using  a  simple 
example.  We  will  model  some  aspects  of  a  secure  distributed 
operating  system  (SDOS).  (This  example  is  a  simplification  of 
the  design  described  in  [V+SS].)  A  system  is  distributed  if  it  is 
composed  of  a  network  of  computers  with  no  shared  memory. 
An  operating  system  is  distributed  if  it  can  service  requests  so 
that  the  location  of  the  resources  used  to  handle  those  requests 
is  transparent  to  the  user.  In  tills  oxample,  we  will  model  how 
messages  can  flow  securely  through  such  a  system.  Since  it  is 
distributed,  requests  from  a  user  may  have  to  be  serviced  by  a 
different  host  than  the  one  the  request  was  made  on.  Itenco, 
not  only  must  a  message  be  routed  to  the  right  location,  but 
sometimes  the  location  may  have  to  bo  found  first.  We  will  call 
the  task  which  actually  does  the  routing  of  messages  the  'message 
switch'  and  the  task  which  makes  the  determination  of  a  host  to 
handle  the  message  the  'locator', 

We  first  need  to  construct  an  overview  of  the  system  consisting 
of  a  collection  of  interconnected  hosts  and  users  (figure  1).  This 
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Figure  I:  Multiple  Hosts  with  Multiple  Users 

might  be  done  by  the  following  sequence  of  steps,  First  we  create 
and  connect  icons  representing  a  particular  host  (called  an  SDOS 
nodej  and  a  set  of  users.  Now  we  create  a  virtual  component 
to  represent  that  any  arbitrary  set  of  interconnections  between 
nodes  is  to  occur  and  then  connect  it  to  the  SDOS-users  icons. 

We  can  then  provide  a  more  detailed  description  of  each  SDOS 
node  (figure  2).  We  use  the  refinement  operation  to  open  up  the 
SDOS  node  and  proceed  to  add  more  detail  inside  of  it.  In  this 
case  we  have  decided  to  break  up  tile  functions  of  SDOS  into  four 
categories.  TIP’s  are  the  processes  which  handle  communications 
witli  tlie  users,  and  the  NET  is  the  process  which  handles  comma  ■ 
nicalion  with  the  actual  network  protocol.  The  Kernel  handles 
tlie  most  essential  operations  of  the  system.  Tlie  other  kinds  of 
processes  are  divided  into  two  boxes  representing  other  managers 
and  processes,  (Note  that  we  must  explicitly  perform  an  opera¬ 
tion  which  connects  tlie  SDOS  users  to  the  TIP  processes.)  in 
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Figure  2:  A  particular  host 

this  presentation  we  only  care  about  the  system  operations  which 
relate  to  message  handling,  and  these  are  contained  within  the 
Kernel.  We  may  consider  the  other  process  icous  as  place  holders 
for  possible  future  refinement  of  the  model. 

We  can  further  refine  the  picture  by  describing  the  structure 
of  the  Kernel  (figure  3).  In  particular  the  Kernel  contains  the 


Figure  3:  The  Kernel 

message  switch  and  other  management  tasks.  One  of  these  man¬ 
agement  tasks  is  the  locator.  Finally  we  connect  the  message 
switch  icon  to  the  other  processes  outside  of  the  Kernel, 

The  graphics  system  not  only  constructs  and  displays  the  model, 
but  it  also  constructs  the  security  theory  of  the  example.  It 
uses  assumptions  or  theorems  about  the  underlying  components 
to  infer  what  is  true  about  the  systems  which  contain  them. 
It  also  useB  information  about  the  components  to  enforce  the 
requirement  that  only  the  appropriate  connections  are  made.  In 
the  example,  the  Ulysses  system  can  infer  that  the  entire  model 
is  flow-secure  once  it  has  been  verified  that  each  of  the  pieces  is 
secure. 

3.3  Textual  Specification  Interface 

Atomic  processes  are  ones  that  are  not  subdivided  further  in  the 
graphical  representation,  The  graphics  system  generates  condi¬ 
tions  implying  that  all  atomic  processes  and  larger  subsystems 
have  been  legally  hooked-up;  these  conditions  are  usually  trivial 
and  can  be  discharged  automatically  by  the  theorem-prover.  If 


all  the  connections  between  components  are  legal,  then  by  com- 
posability  we  can  verify  that  the  composite  system  is  flow  secure 
by  establishing  that  each  atomic  component  is  flow  secure.  For 
some  simple  cases,  the  proof  that  a  component  is  flow  secure 
can  be  done  automatically;  in  general,  though,  it  is  necessary  to 
examine  or  refine  the  component  using  the  textual  specification 
interface. 

The  security  of  a  component  depends  on  its  functionality.  The 
textual  interface  allows  us  to  describe  the  functionality  of  a  com¬ 
ponent  by  giving  a  state  machine  representation  of  its  behavior. 
This  representation  consists  of  the  definitions  of  the  data  types 
involved  in  the  internal  state  parameters  of  the  component  and 
in  the  messages  that  the  component  uses  to  communicate,  to¬ 
gether  with  axioms  describing  the  possible  state  transitions  of 
the  component  and  the  security  levels  associated  with  messages 
and  internal  parameter  information.  From  the  state  machine 
representation  of  a  component,  the  statement  of  flow  security  for 
that  component  can  be  generated  automatically. 

The  state-machine  model,  the  theory  of  security,  and  tactics  for 
proof  of  security  for  particular  processes,  are  all  connected  via 
the  textual  interface  to  the  logical  formalism  described  in  section 
4.  Flow  security,  as  well  as  other  properties  of  components,  can 
thus  be  verified  by  reasoning  in  the  underlying  logic. 

3.4  Natural  Language 

The  text  generation  component  of  Ulysses  is  intended  to  serve 
two  purposes:  First,  to  provide  annotations  and  comments  to 
aid  the  designer  during  the  design  process;  second,  to  produce 
an  overview  of  the  system,  including  its  security  characteristsics, 
once  the  design  has  been  completed.  As  practical  experience 
with  the  design  process  is  still  limited,  efforts  have  concentrated 
on  the  second  application. 

The  design  of  a  system  in  Ulysses  is  determined  graphically  and 
(in  the  case  of  atomic  components)  by  the  textual  formal  specifi¬ 
cation,  Typically,  such  designs  would  be  accompanied  by  manu¬ 
ally  written  annotations,  Annotations  complement  diagrams  and 
formal  specifications  by  giving  an  informal  rationale  behind'  the 
design  and  its  structure.  Annotations  summarize  the  function¬ 
ality  of  the  design  components  and  explain  them  by  appealing 
to  concepts  shared  by  the  designer  and  the  reader  of  the  anno¬ 
tations.  Such  annotations  become  indispensable  in  the  context 
of  a  secure  design;  these  usually  involve  some  compromise  be¬ 
tween  functional  requirements  and  security  considerations  that 
need  explanation  or  justification. 

The  text  generation  component  of  Ulysses  is  a  pioneering  attempt 
to  generate  annotations  automatically.  During  the  first  stage 
of  our  work,  the  emphasis  is  on  producing  texts  that  describe 
the  security  features  of  the  system  with  less  attention  paid  to 
functionality. 

The  information  about  how  security  is  enforced  in  the  system  is 
derivable  from  the  history  of  the  security  proof  for  the  compo¬ 
nent,  Thus  a  user  who  is  not  familiar  with  a  given  design  would 
have  to  consult  three  different  sources  -  graphical  design,  formal 
specification,  security  proof  -  and  synthesize  an  understanding 
of  th«  system  himself.  It  is  this  job  of  synthesis  that  the  natural 
langu.  je  generation  component  performs. 

The  area  of  text  generation  of  system  documentation  has  not 
yet  been  studied  by  either  linguists  or  computer  scientists,  How- 


23 


ever,  highly  promising  and  effective  systems  exist  for  other  do¬ 
mains  (for  example  McKeown’s  interface  to  a  naval  data  base, 
[McK85]).  Such  work  has  allowed  us  to  build  on  existing  general 
techniques  and  concentrate  on  specific  problems  arising  in  our  do¬ 
main  of  annotations  of  secure  designs.  At  present,  the  generation 
component  of  Ulysses  produces  multi-paragraph  texts  about  sys¬ 
tems  such  as  the  Secure  Distributed  Operating  System  (SDOS) 
[V+88], 

The  text  generation  requires  computation  at  three  levels:  text 
planning,  sentence  planning  and  sentence  generation,  described 
below. 

Text  planning  assembles  a  series  of  conceptual  representations 
that  determine  the  contents  and  organization  of  the  text,  For¬ 
mally,  the  approach  used  is  inspired  by  that  of  McKcown:  schemata 
encode  recurring  textual  patterns  and  access  the  available  knowl¬ 
edge.  However,  there  is  no  homogenous  knowledge  representation 
in  Ulysses  that  the  text  generator  can  use.  Instead,  it  uses  any 
information  that  is  available  such  us: 

u  the  decomposition  of  the  system  into  communicating  com¬ 
ponents,  as  defined  by  the  user  through  the  graphical  in¬ 
terface 

a  the  security  characteristics  of  individual  components  as  they 
are  determined  during  the  proof,  and  the  proof  strategies 
used 

o  domain-specific  knowledge  about  different  types  of  systems 
(operating  systems,  gateways,  LANs,  etc.) 

o  certain  information  the  user  has  entered  alter  being  prompted 
by  Ulysses 

However,  this  information  about  the  system  is  not  yet  in  a  for¬ 
mat  that  could  be  accessed  by  a  general  text  planner;  instead, 
the  available  information  needs  know  ledge- based  interpretation 
in  order  to  serve  as  the  basis  for  informative  and  meaningful 
texts.  This  is  particularly  true  of  the  description  of  the  system’s 
security  features.  Certain  typical  security  strategics  need  to  bo 
inferred  from  the  structure  of  the  system  and  the  level  of  secu¬ 
rity  of  the  components.  For  example,  component  which  serve 
a a  mediators  of  communication  between  other  components  must 
figure  more  prominently  in  the  security  analysis.  The  knowledge 
needed  for  interpretation  is  encoded  directly  in  the  schemata, 
which  makes  text  planning  efficient  but  restricts  it  to  the  do¬ 
main  of  secure  system  design. 

Sentence  planuing  takes  the  sequence  of  conceptual  representa¬ 
tions  and  transforms  it  into  a  sequence  of  sentence  representa¬ 
tions.  The  transformation  involves  message  combination  (de¬ 
termining  sentence  boundaries),  syntactic  decisions  (determining 
sentence  structure)  and  lexioalization  (choosing  English  words  for 
the  concepts). 

Sentence  generation  produces  an  English  sentence.  The  gener¬ 
ation  component  is  based  on  Meaning- Text  Theory  [Mel81).  It 
defines  a  series  of  transformations  from  the  sentence  represen¬ 
tation  (tlie  deep-syntactic  representation)  to  the  surface  string, 
thus  localizing  linguistic  decisions  at  particular  levels. 


SDDS:  General  Structure  and  Security  Feature* 

A  SDOS  i>  a  eecur*  distributed  operating  system.  It  ia  a 
collection  of  distributed  SDOS  nodes  connected  by  a  net.  The 
net  is  the  only  link  between  them.  Each  SDOS  node  aupports  a 
group  of  Users.  They  havo  access  to  operating  eye tern  services 
only  through  their  SDOS  node.  In  the  SDOS  security  is  enforced 
locally  by  the  multilevel  secure  SDOS  nodes.  The  Users  are 
modeled  as  singlelevel  trusted  or  multilevel  secure. 

Each  SDOS  node  is  a  complex  subsystem  and  consists  of  a  Kernel , 
a  Vetvork  Interface  and  groups  of  TIPs,  of  Processes  and  of 
Managers.  The  Managers,  the  TIPs,  the  network  Interface  and 
the  Processes  communicate  only  through  the  Kernel.  The  Kernel 
ie  multilevel  secure  and  enforces  the  security  of  the  SDOS 
node.  The  Managers  and  the  Processes  provide  operating  system 
services.  The  Managers  can  be  singlelevel  trusted  or 
multilevel  secure;  the  Processes  are  untrusted.  The  TIPe  serve 
at  interface  to  the  Usere.  They  can  be  singlelevel  trusted  or 
multilevel  secure.  The  multilevel  secure  Network  Interlace 
handles  communication  with  the  net. 

The  Xemel  is  a  composite  subsystem  and  consists  of  a  Kernel 
Manager  and  a  Message-Switch.  The  Heeeage-Svitch  mediates 
communication  between  the  TIPs,  the  Managers,  the  Processes  and 
the  Network  Interface.  It  is  multilevel  secure  and  enforces 
the  security  of  the  Kernel.  The  multilevel  secure  Kernel 
Manager  support*  its  activity. 

Figure  '1:  The  SDOS  Text 

3.5  Library  of  Models 

The  function  of  the  library  is  to  provide  and  organize  informa¬ 
tion  useful  ill  the  design  and  verification  of  systems.  The  library 
contains  three  major  kinds  of  information: 

1.  System  descriptions.  Both  the  specifications  of  atomic  com¬ 
ponents  and  interconnections  of  complex  system  designs 
built  from  the  components  arc  stored  in  the  library.  The 
status  of  what  lias  been  proven  about  the  security  of  the 
components  and  of  the  systems  is  also  maintained. 

2.  Security  Theory  and  other  Mathematical  facts.  The  library 
maintains  a  store  of  information  describing  the  security  the¬ 
ory  and  other  relevant  mathematical  facts.  Also  included 
are  definitions  of  the  tactics  and  theories  used  by  the  the¬ 
orem  prover. 

3.  Graphical  presentation.  The  system  can  record  various 
facts  about  the  graphical  layout  of  designs,  This  informa¬ 
tion  is  in  addition  to  the  design  information  of  the  theories. 

Tlie  library  will  contain  a  variety  of  designs  of  generic,  commonly 
used  software  systems  ranging  from  very  small  components,  such 
as  buffers  or  queues,  to  complex  ones,  such  as  a  Database  Man¬ 
agement  System.  The  list  of  secure  designs  includes  some  generic 
trusted  processes  (multilevel  buffers,  secure  separators,  secure 
schedulers),  a  Local  Area  Network  (several  designs  for  different 
medium  access  control),  a  Multinct  Gateway,  a  Database  Man¬ 
agement  System,  a  Distributed  Operating  System,  and  several 
others.  The  user  will  be  able  to  study  library  designs  and  their 
associated  documentation  and  to  use  them  in  his  own  designs. 
The  user  can  either  use  library  designs  as  “building  blocks”  and 
rely  on  proofs  done  by  Ulysses'  developers,  or  change  library  de¬ 
signs  according  to  the  requirements  of  his  or  her  system. 

Ulysses  will  support  browsing  through  the  library  for  components 
or  other  theories  that  meet  given  criteria. 


Figure  4  shows  an  annotation  of  SDOS  generated  by  the  system. 
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The  theory  of  security  currently  used  in  Ulysses  is  merely  a  de¬ 
fault.  It  is  one  particular  set  of  theorems  about  the  hook-up  of 
components  into  systems,  Other  theories  of  security  are  possible. 
For  example,  a  precise  theory  of  components  that  are  “almost  se¬ 
cure”  might  be  definable,  and  facts  about  their  hook-up  proved. 
Users  may  add  such  new  theories  to  the  library. 

4  The  Mathematical  Component 

The  goal  of  the  Ulysses  project  is  to  understand  security  at  the 
design  level  and  to  automate  that  understanding  in  a  logically 
coherent  formal  setting.  We  believe  that  a  general  mathematical 
theorem- proving  environment  based  on  type  theory  is  a  good 
foundation  for  this  task. 

We  will  explain  what  this  assertion  means  and  what  our  reasons 
for  believing  it  are  in  the  following  way.  Wo  begin  with  a  general 
sketch  of  the  mathematical  component’s  design.  Then  we  discuss 
its  antecedents  (subsection  4.1),  explain  how  mathematics  will 
be  expressed  within  this  framework  (subsection  4.2),  and  say 
why  this  setting  is  especially  suited  to  work  on  security  modeling 
(subsection  4.3).  The  remainder  of  the  section  will  be  devoted 
to  some  brief  remarks  about  technical  aspects  of  the  design — 
the  underlying  logic  (subsection  4.4),  the  core  component  of  the 
logic's  implementation  (subsection  4.5),  and  theory  management 
(subsection  4.6). 

Within  the  mathematical  component,  the  word  “theory”  lias  a 
technical  sense.  But  this  technical  usage  reflects  accurately  many 
important  facets  of  the  term’s  ordinary  meaning.  Intuitively,  a 
theory  is  a  collection  of  reluted  facts  and  notations  for  express¬ 
ing  them.  The  facts  collected  in  theories  may  be  related  in  a 
number  of  ways  —  they  may  be  stated  in  a  common  language, 
may  depend  on  common  axioms,  and  may  support  one  another 
in  various  fashions  in  tiic  sequential  development  of  a  theory. 

Facts  and  notation  may  be  incorporated  into  a  theory  by  relying 
on  a  previously  developed  theory,  by  introducing  a  notational 
abbreviation,  by  introducing  a  definition,  by  postulating  a  new 
axiom,  by  stating  and  proving  a  theorem,  and  by  introducing  all 
of  the  facts  and  notations  from  some  other  theory  after  show¬ 
ing  that  all  of  its  assumptions  are  satisfied  in  the  theory  being 
developed. 

The  mathematical  component  provides  a  rigorous  setting  within 
which  all  of  these  features  of  our  informal  conception  of  theories 
are  represented  precisely  and  usefully, 

Theories  have  two  main  parts:  a  precis,  which  identifies  the  lin¬ 
guistic  dependencies  and  states  the  postulates  of  a  theory,  and  a 
body,  which  contains  the  development  of  new  facts  and  notation 
introduced  by  the  theory.  In  the  context  of  a  library  of  theories, 
the  precis  determines  the  initial  environment  of  a  theory.  That 
is,  it  determines  the  collection  of  facts  and  notation  imported 
from  other  theories  directly.  In  addition,  it  contains  the  axioms 
and  new  symbols  characteristic  of  the  theory  under  development. 
The  body  extends  the  environment  of  facts,  assumptions  and  no¬ 
tation  defined  by  the  precis.  Essentially,  the  meaning  of  a  theory 
is  the  incremental  extension  of  the  initial  environment  which  the 
body  provides. 

Ulysses  is  based  on  a  version  of  type  theory  capable  of  expressing 
both  classical  and  constructive  mathematics.  Within  the  mathe¬ 
matical  component  of  the  system,  the  relationship  between  theo¬ 


ries  of  security  and  the  semantics  of  their  specification  languages 
is  expressed  rigorously,  for  theories  which  permit  it.  In  particu¬ 
lar,  this  has  been  done  for  flow  security.  This  formal  foundation 
will  reduce  the  consistency  question  for  the  logic  and  the  cor¬ 
rectness  question  for  the  theorem  prover,  to  the  consistency  and 
correct  implementation  of  the  six  rules  of  the  underlying  type 
theory, 

4.1  History 

The  idea  of  using  type  theory  for  the  expression  of  mathemat¬ 
ics  in  a  theorem  proving  environment  was  first  championed  by 
de  Bruijn  in  the  AUTOMATII  system  [BiuSO],  The  aim  of  AU- 
TOMATII  was  to  verify  mathematical  “books”.  The  system  was 
very  batch  oriented,  originally  reading  the  “book"  as  a  deck  of 
punched  cards. 

In  the  early  eighties.  Constable  and  his  students  at  Cornell  Uni¬ 
versity  began  another  major  project  to  express  mathematics  in 
type  theory  called  the  “prl"  project  [C+86],  (“prl”  is  short  for 
“Proof  Refinement  Logic"  and  is  pronounced  “pearl”.)  Their 
work  was  inspired  by  the  AUTOMATII  project  and  by  the  work  of 
the  logician  Per  Martin-Lof  [Mar82).  Their  aim  was  not  just  to 
provide  an  environment  for  the  verification  of  mathematics,  but 
to  assist  users  in  developing  mathematical  theories  interactively, 

The  key  idea  that  made  this  possible  was  the  concept  of  a  re¬ 
finement  style  proof  editor  [Bat79].  Such  a  proof  editor  allows 
the  user  to  state  a  theorem  and  then  construct  a  proof  interac¬ 
tively  by  manipulating  subderivations  displayed  on  the  screen. 
This  can  be  done  either  by  directly  invoking  the  primitive  rules 
of  the  system  or  by  invoking  tactics  which  direct  the  machine  to 
do  these  micro-inferences  automatically. 

The  tactic  mechanism  lias  proved  to  be  a  vital  feature  of  the  sys¬ 
tems  developed  during  the  prl  project,  and  it  plays  uu  equally  im¬ 
portant  role  in  Ulysses.  The  meta-language  of  the  prl  systems  is 
ML  [Mil78],  which  was  developed  to  provide  the  meta-language 
of  LCF  [GMW79).  The  same  is  true  of  our  system.  Tactics 
are  segments  of  ML  code  which  extend  the  primitive  inferential 
apparatus  of  the  logics  on  which  these  systems  are  based.  The 
systems’  proof  checking  mechanisms  insure  that  these  extensions 
arc  sound. 

In  principle,  it  would  be  possible  to  write  a  general  theorem  prov¬ 
ing  program  and  rely  on  it  as  one’s  sole  tactic.  But  experience 
with  the  prl  systems  has  shown  that  it  is  more  productive  to  de¬ 
sign  tactics  for  specific  circumstances  encountered  in  developing 
mathematical  theories.  The  tailoring  of  tactics  to  the  special 
requirements  of  security  modeling  is  one  of  the  most  important 
features  of  the  mathematical  component  of  Ulysses. 

Although  the  design  of  the  mathematical  component  drawo  heav¬ 
ily  from  the  experience  of  the  prl  project,  there  are  two  primary 
differences.  The  first  is  the  choice  of  the  underlying  logical  system 
and  the  second  is  the  addition  of  a  facility  for  modular  theories, 
These  two  issues  are  related:  the  logical  base  we  have  chosen  sup¬ 
ports  modularity  much  more  easily  than  does  the  type  theory  on 
which  prl  is  founded  [Sel88]. 

In  addition  to  these  differences,  there  are  several  design  differ¬ 
ences  that  are  expected  to  give  Ulysses  significantly  better  per¬ 
formance  than  the  Nuprl  system  (the  new  and  current  version 
of  prl)  and  allow  the  mathematical  component  to  be  integrated 
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with  other  system  components.  One  of  these  is  the  use  of  graph 
reduction  to  handle  necessary  computations  in  the  underlying 
lambda  calculus  (subsectio.,  4.5).  Another  is  the  treatment  of 
definitions.  We  discuss  this  briefly  now  and  return  to  the  topic 
in  subsection  4.6. 

For  Ulysses  to  be  used  successfully,  the  mathematics  expressed 
in  theories  must  be  visually  similar  to  mathematics  as  it  is  ordi¬ 
narily  written,  and,  when  the  mathematical  component  is  used 
as  part  of  a  domain  specific  system,  domain  specific  information 
must  be  presented  to  the  user  in  a  recognizable  form.  Conse¬ 
quently,  there  must  be  a  very  powerful  mechanism  for  extending 
the  not  '.lion  of  the  system.  This  feature  is  called  the  definition 
facility,  and  the  concerns  expressed  in  tile  first  sentence  of  this 
paragraph  played  a  major  role  in  shaping  its  design. 

4.2  Expressing  Mathematics  and  Security 
Theories 

Once  the  foundation  of  the  system  is  laid,  the  next  step  is  to 
express  something  in  it.  That  requires  developing  familiar  math¬ 
ematical  concepts,  such  as  elementary  arithmetic,  simple  set  the¬ 
ory,  u  theory  of  sequences,  and  some  simple  computational  mod¬ 
els  within  the  system.  These  theories  will  be  included  in  the 
system  library.  The  theory  manager  enforces  a  presupposition 
structure  specifying  which  other  theories  must  be  included  in 
the  current  environment  if  a  given  theory  is  to  be  used. 

Once  all  of  these  basic  pieces  of  mathematics  are  in  place,  the 
theory  of  security  is  formulated  and  theories  describing  exam¬ 
ple  systems  are  synthesized  within  Ulysses.  This  collection  of 
theories  forms  an  experimental  testbed  for  the  automation  of 
security  reasoning.  The  automation  will  be  provided  by  combin¬ 
ing  the  ML  mechanism  tliut  provides  assistance  in  proofs  witli 
supplementary  code  written  in  Common  Lisp.  Besides  supplying 
assistance  ill  proofs,  the  system  will  provide  support  for  formulat¬ 
ing  appropriate  security  theorems  and  for  integrating  previously 
defined  structures  iuto  the  current  environment. 

We  expect  that  once  we  have  developed  a  library  of  verified, 
composably  secure  components,  most  Ulysses  users  will  bo  able 
to  view  the  system  as  a  fully  automated  theorem  prover,  and  not 
as  a  proof  development  environment.  The  sophisticated  user  will 
have  the  opportunity,  however,  to  invoke  any  mathematical  facts 
that  can  bo  developed  within  the  system  wlion  arguing  formally 
that  a  system,  or  system  component,  is  secure.  And  the  system 
designers  will  have  confidence  that  all  of  the  components  they 
have  supplied  to  the  users  are,  in  fact,  secure  according  to  the 
formal  definition  of  security  axiomatized  within  the  system. 

Besides  providing  a  formal  framework  in  which  to  pursue  the 
current  goals  of  the  Ulysses  project,  the  system  design  allows  for 
the  development  of  extended  versions  which  will  incorporate  a 
code  verification  facility.  We  believe  that,  ultimately,  this  formal 
foundation  will  make  Ulysses  a  trustworthy  robust  system  de¬ 
velopment  environment.  Of  couise,  whether  wo  are  right  can  be 
determined  only  by  developing  such  an  environment  and  bringing 
tlio  result  before  the  bar  of  experience  for  judgment. 

4.3  Advantages  for  security  modeling 

A  number  of  features  of  the  mathematical  component  make  it  an 
especially  useful  tool  for  dealing  with  security  modeling.  Chief 


among  these  is  the  tactic  mechanism.  We  are  creating  a  library  of 
tactics  tailored  to  the  demands  of  proving  security  results  about 
the  sorts  of  models  most  commonly  dealt  with.  This  library  will 
greatly  enhance  the  usefulness  of  Ulysses, 

Quite  often,  it  is  possible  to  restrict  attention  to  a  class  of  security 
models  considerably  smaller  and  simpler  than  tiic  class  of  all  such 
models,  and,  for  such  models,  it  is  fairly  simple  to  prove  what 
needs  to  be  shown  about  the  processes  involved,  in  such  cases, 
we  are  going  to  automate  the  proof  process  almost  completely 
by  writing  appropriate  tactics. 

For  example,  many  processes  accept  an  input,  emit  some  outputs, 
and  then  process  the  next  input.  For  these  kinds  of  processes,  one 
can  use  a  security  tactic  whicii  converts  the  goal  of  proving  flow 
security  into  simpler  kinds  of  conditions.  It  suffices  to  show  that 

(1)  for  any  given  input  there  will  be  only  finitely  many  outputs, 

(2)  the  security  level  of  an  output  13  always  greater  than  or  equal 
to  the  level  of  the  input,  (3)  the  content  of  the  output  is  based 
only  on  the  input  and  information  carried  by  parameters  at  or 
below  the  level  of  the  input,  and  (4)  high  level  inputH  do  not 
change  the  low  level  characteristics  of  these  parameters.  See 
[Ilos88]  for  more  details. 

Another  important  characteristic  of  the  mathematical  compo¬ 
nent  is  its  expressive  power.  Witli  this  system  it  is  relatively 
easy  to  build  new  abstract  data  types.  This  makes  descriptions 
of  models  easier  to  understand  and  allows  for  more  accurate  de¬ 
scriptions.  Descriptive  power  also  enables  the  user  to  formulate 
properties  of  a  process  more  easily.  For  cxuiuplc,  it  is  easy  to 
assort  within  the  language  that  a  process  halts.  Also,  the  secu¬ 
rity  theory  is  built  directly  into  the  system.  This  insures  that 
proving  that  a  system  has  the  properties  specified  by  the  theory 
really  does  show  it  is  secure,  in  the  sense  specified  by  the  theory. 

A  third  useful  aspect  of  the  proof  development  environment  is 
that  it  allows  security  results  to  be  proven  about  generic  descrip¬ 
tions  and  not  just  particular  instances  (see  subsection  4.4).  This 
means  that  most  adjustments  to  a  model  will  require  little  if 
any  work  in  reconstructing  proofs  of  security  for  it.  Often,  the 
modeling  environment  will  do  all  the  necessary  reconstruction, 
without  intervention  from  the  user  —  if  you  want  to  add  new 
components  to  a  modol,  demonstrating  security  may  involve  no 
direct  effort  on  your  part. 


4.4  The  logic 

The  logical  system  underlying  Ulysses  is  the  theory  of  construc¬ 
tions  of  Coquaud  and  Iiuet  [CHS4],  [CIIS6],  [Hue87],  [Sel88], 
[Pot87].  Besides  providing  a  quite  expressive  logical  system,  the 
theory  of  constructions  also  includes  a  powerful  model  of  com¬ 
putation.  The  model  of  computation  is  not  important  for  the 
current  aims  of  the  Ulysses  project,  but  we  expect  to  rely  on  it 
in  future  extensions  of  the  system. 

There  arc  only  two  built-in  types  in  the  theory,  but  there  is  a 
facility  for  reasoning  in  the  context  of  type  assumptions  that  de¬ 
scribe  both  the  operations  and  axioms  of  mathematical  theories, 
This  mechanism  supports  an  abstract  style  of  theory  develop¬ 
ment.  Suppose  group  theory  has  been  developed  in  a  context 
that  i  /ecifies  the  operations  and  axioms  characteristic  of  groups. 
It  will  be  possible  to  instantiate  this  abstract  theory  on  a  par¬ 
ticular  structure  by  specifying  which  operations  of  the  structure 
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are  to  play  the  role  of  the  group  operations  and  proving  that  the 
group  axioms  are  satisfied  by  the  specified  operations, 

The  theory  of  constructions  contains  a  type  which  formally  repre¬ 
sents  the  type  of  all  propositions.  In  turn,  this  type  is  contained 
in  a  type  which  satisfies  very  strong  closure  conditions,  Con¬ 
sequently,  the  theory  contains  full,  higher  order  logic  —  having 
specified  a  ground  type  by  means  of  appropriate  assumptions, 
one  can  refer  to  properties  of  the  ground  objects,  properties  of 
such  properties,  functions  from  properties  of  the  latter  sort  to 
those  of  the  former,  and  so  on,  without  limit. 

The  logic  provided  by  the  theory  of  constructions  is  constructive. 
This  is  noteworthy  for  two  reasons,  First,  it  is  the  key  reason 
why  the  theory  includes  a  model  of  computation.  Second,  it 
means  that  the  logic  is  richer  than  classical,  two  valued  logic  — 
constructivity  is  an  enhancement,  not  a  restriction. 

The  theory  of  constructions  provides  a  model  of  computation  in 
which,  besides  taking  types  as  arguments,  functions  can  return 
types  as  values.  Furthermore,  the  type  of  the  value  returned  by  a 
function  can  depend  on  the  argument,  and  not  merely  on  the  ar¬ 
gument's  type.  Consequently,  the  theory  is  of  great  interest  from 
the  point  of  view  of  research  on  polymorphism  in  programming 
languages. 

This  model  of  computation  is  extremely  powerful.  Formal  mea¬ 
sures  of  its  power,  relying  on  the  results  of  [Gir71,Gir72],  show 
that  it  is  strong  enough  to  represent  any  computable  (total)  num¬ 
ber  theoretic  function  considered  in  ordinary  mathematical  prac¬ 
tice,  and  this  is  a  tower  bound.  An  informative  upper  bound  on 
the  strength  of  the  model  of  computation  built  into  tiic  theory 
of  constructions  has  not  yet  been  established, 

As  far  as  correctness  is  concerned,  Coquaud  has  shown  that  the 
logic  embodied  in  the  theory  of  constructions  is  consistent  and 
that  all  computations  in  the  model  of  computation  terminate. 
Taken  together  with  tile  features  of  the  theory  discussed  above, 
this  explains  why  the  theory  of  constructions  is  interesting,  both 
from  a  purely  logical  standpoint  and  from  the  point  of  view  of 
theoretical  computer  science,  it  also  led  to  the  decision  to  base 
the  mathematical  component  of  Ulysses  on  the  theory  of  con¬ 
structions. 


4.5  The  Primitive  Inference  Engine 

The  core  of  the  mathematical  component  is  the  Primitive  in¬ 
ference  Engine  (PIE).  The  PIE  includes  a  proof  checker  for  the 
theory  of  constructions  and  rudimentary  (but  extensible)  tools 
for  proof  development.  We  arc  proceeding  on  the  basis  of  a  for¬ 
mulation  of  the  theory  of  constructions  which  is  especially  suited 
to  the  character  of  the  proof  development  tools  and  also  allows 
for  efficient  proof  checking  [PotSSaj, 

The  central  computational  problems  involved  in  implementing 
this  formal  system  have  to  do  with  handling  substitution,  reduc¬ 
tion  and  conversion  of  terms.  Wo  have  reduced  these  problems  to 
their  essence  by  representing  terms  of  the  theory  of  constructions 
in  the  simpler  framework  provided  by  the  type-free  lambda  cal¬ 
culus  and  have  done  the  same  thing  for  the  relations  of  reduction 
and  conversion  [PotSSaj. 

Recasting  the  computational  problems  in  this  way  is,  of  course, 
only  a  beginning.  An  efficient  implementation  of  the  type-free 


lambda  calculus  will  be  produced  by  using  graph  reduction  [Wad71, 
Tur79], 

4.6  Theory  management 

As  was  remarked  in  subsection  4,1,  in  many  important  respects 
the  mathematical  component  of  Ulysses  is  modeled  after  Nuprl. 
We  end  this  section  by  commenting  briefly  on  two  important 
differences, 

It  is  reasonable  to  say  that  proofs  of  hook-up  security  require  a 
Biuall  mathematical  foundation,  if  “small”  is  understood  in  the 
sense  of  the  term  customary  among  mathematicians.  But  actu¬ 
ally  providing  such  a  foundation  requires  building  a  complicated 
structure  in  the  machine.  Definitions  are  common  and  vital  com¬ 
ponents  of  this  structure,  so  it  is  important  to  have  an  efficient 
way  of  handling  them.  Our  approach  to  this  problem  is  quite 
different  from  the  one  taken  by  Nuprl,  and  we  think  it  will  turn 
out  to  bo  superior  [PotSSbj. 

It  is  also  certain  that  we  must  develop  theories  modularly,  if 
Ulysses  is  to  be  practically  useful.  It  should  be  clear  from  the 
discussion  of  this  section  that  this  concern  is  handled  adequately 
in  the  system  we  are  constructing.  In  contrast  with  this,  Nuprl 
provides  no  mechanisms  for  modular  theory  development,  and 
certain  features  of  the  logical  system  on  which  Nuprl  is  based 
make  the  project  of  introducing  such  mechanisms  problematic. 
This  reinforces  our  conviction  that  the  theory  of  constructions, 
which  directly  supports  modularity  in  developing  theories,  is  a 
good  choice  for  the  logical  basis  for  security  modeling  in  Ulysses. 


5  Implementation 

A  U  ysscs  system  that  implements  the  functions  described  in 
previous  sections  is  now  being  built  at  ORA.  By  October  1st,  we 
expect  to  have  a  functional  prototype.  The  prototype  version  will 
run  under  Symbolics  Genera  7.1.  However,  we  have  placed  great 
emphasis  on  portability  even  at  early  stages  in  the  development. 
Most  of  the  source  code  is  written  in  Common  Lisp  or  one  of  its 
object-oriented  extensions  (Symbolics  Common  Lisp  or  CLOS); 
the  only  exceptions  are  the  tactics,  which  are  written  in  a  version 
of  ML  that  is  itself  implemented  in  Common  Lisp.  Symbolics 
Common  Lisp  will  be  converted  into  CLOS  and  u.ti,  with  a  set  of 
translation  macros.  As  a  result,  only  a  minimum  of  effort  should 
be  involved  in  re- targeting  Ulysses  to  any  oilier  architecture  that 
supports  Common  Lisp;  most  of  this  effort  will  relate  to  the 
graphical  interface. 


G  Conclusion 

The  design  of  Ulysses  incorporates  ideas  and  techniques  from  a 
diverse  collection  of  sources,  including  those  in  computer  security, 
systems  design,  computational  logic,  and  computational  linguis¬ 
tics  in  order  to  create  a  modeling  environment  with  both  rigor 
in  its  theoretical  foundations  and  flexibility  in  its  use.  Because 
of  the  nature  of  the  theorem  prover  and  the  overall  design  of  the 
system,  it  has  the  potential  to  significantly  reduce  the  time  and 
effort  needed  in  constructing  secure  models. 
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Abstract 

In  this  paper,  the  integrity  policy 
introduced  by  Clark  and  Wilson  is  taken  as 
a  set  of  valid  requirements  suitable  for 
commercial  and  other  data  processing 
requirements  that  must  be  enforced  with  a 
high  level  of  assurance.  A  methodology 
for  converting  a  policy  expressed  in  terms 
of  the  Clark/Wilson  notation  into  a 
corresponding  mandatory  policy  expressed 
in  terms  of  a  lattice  of  access  classes, 
together  with  an  appropriate  supporting 
policies  for  identification  and 
authentication  is  stated.  The  existence 
of  such  a  methodology  implies  that  the 
Clark/Wilson  integrity  requirements  can  be 
met  by  existing,  appropriately-configured 
Trusted  Computing  Bases. 


1 .  Introduction 

The  integrity  policy  presented  by 
D.D. Clarke  and  D.R. Wilson  in  [1]  has 
received  a  relatively  high  degreo  of 
attention  as  an  accurate  representation  of 
what  the  business  and  commercial  data 
processing  community  means  by  the  term 
integrity  with  respect  to  data  processing 
applications  oriented  toward  commercial 
applications,  just  as  the  Beil  and  LaPadula 
formal  security  policy  model  [2]  has 
served,  in  the  past,  as  the  technical  basis 
for  trusted  computer  systems  enforcing  a 
mandatory  access  control  policy  oriented 
toward  military  and  government  applications 
processing  information  classified  under 
federal  regulation. 

Clark  and  Wilson  state,  as  their  two  major 
conclusions,  that  "a  lattice  model  is  not 
sufficient  to  characterize  integrity 
policies",  and  that  "distinct  mechanisms 
are  needed  to  control  disclosure  and  to 
provide  integrity".  The  implication  of 
these  conclusions,  if  true,  is  that  the 
Trusted  Computing  Base  technology  described 
in  [3]  are  not  applicable  to  the  evaluation 
of  systems  designed  to  enforce  the 
Clark/Wilson  integrity  policy. 

In  this  paper,  issue  is  taken  with  both  of 
these  conclusions.  The  argument  has  the 
following  outline:  starting  with  an 
arbitrary  Clark/Wilson  policy,  an 
equivalent  access  control  policy  based  upon 
a  lattice  of  sensitivity  labels  is  derived. 
Together  with  appropriate  supporting 
controls  for  a  security  officer  interface 
and  identity-based  subject  activation,  a 
policy  interpretation  compliant  with  the 
requirements  of  [3]  can  therefore  be 
formulated.  A  TCB  enforcing  such  a  policy 
would  satisfy  the  Clark/Wilson  policy  as 
well  as  the  Criteria.  As  the  originally 
chosen  integrity  policy  was  arbitrarily 


chosen  from  the  family  of  Clark/Wilson 
policies,  it  follows  that  any  Clark/Wilson 
policy  can  be  enforced  by  an 
appropriately-configured  TCB  meeting  the 
criteria  stated  in  [3]. 

As  the  transformation  is  constructive,  it 
shows  how  an  arbitrary  policy,  expressed  in 
terms  of  the  Clark/Wilson  model ,  can  be 
reformulated  as  an  equivalent  combination 
of  access  controls  based  upon  a  lattice  of 
access  classes  together  with  a 
discretionary  component  controlling  access 
to  the  execution  of  transactions  to  the 
granularity  of  an  individual. 

The  implication  of  this  construction  is 
that  one  could  envision  a  TCB,  designed  to 
be  evaluated  under  the  criteria  of  the  [3] , 
that  is  also  well-suited  to  the  enforcement 
of  controls  expressed  in  terms  of  tho 
Clark/Wilson  model.  In  fact,  it  can 
further  be  observed  that  such  a  TCB  is 
already  available.  In  a  later  section,  I 
will  discuss  how  an  existing  TCB  (Gemini 
Computer’s  GEMSOS )  can  be  tailored  to 
support  a  Clark/Wilson  model. 

1 . 1  Relationship  to  Previous  Work 

Several  papers  earlier  than  [1]  are 
important  in  the  study  of  the  application 
of  computer  security  technology  to 
integrity  issues.  I  have  drawn  freely  from 
them  in  the  work  presented  below.  Biba,  in 
[4]  presents  a  "mandatory  integrity  policy” 
that  is  the  mathematical  dual  of  a 
mandatory  secrecy  policy  based  on  a  lattice 
of  labels.  Such  a  policy  is  often  called  a 
Biba  integrity  policy.  Lipner,  in  [5] 
constructs  a  commercially-oriented  policy 
from  a  combination  of  secrecy  and  mandatory 
integrity  levels  and  categories.  Shirley 
and  Schell,  in  [6]  introduce  the  notion  of 
program  integrity,  a  policy  that  is 
important  when  subjects  that  are  "trusted 
with  respect  to  integrity"  exist  in  a 
system.  They  demonstrate,  in  addition, 
that  a  ring-based  protection  hierarchy, 
such  as  that  found  in  Multics  or  GEMSOS, 
can  be  interpreted  as  a  hierarchical  system 
of  subjects  trusted  (to  various  degrees) 
with  respect  to  integrity,  upon  which  the 
program  integrity  policy  is  enforced. 

Boebert  and  Kain,  in  [7]  introduce  a 
system  of  trusted  pipelines,  enforceable  by 
the  Honeywell  LOCK  (formerly,  SAT)  TCB. 

They  demonstrate  (correctly)  that  a 
hierarchy  of  Biba  integrity  levels  alone  is 
insufficient  to  enforce  a  trusted  pipeline. 
The  generalization  that  a  full  lattice 
including  Biba  integrity  categories  is 
insufficient  as  well  is  not  addressed  by 
Boebert  and  Kain.  This  paper  is  an 


29 


important  predecessor  to  [1]:  indeed,  it 
could  be  fairly  stated  that  the 
Clark/Wilson  policy  is  an  elaboration  of 
the  trusted  pipeline  idea. 

In  addition  to  these,  the  Clark/Wilson 
prt  mentation  has  induced  a  number  of 
additional  papers,  generally  of  the  form 
"system  x  can  enforce  the  Clark/Wilson 
policy."  A  recent  paper  by  Lee,  [3] 
presents  a  construction  identical  in  many 
respects  to  the  system  presented  here.  The 
primary  deficiency  in  Lee's  paper  is  that 
one  of  the  important  Clark/Wilson 
constraints,  requiring  that  controls  be 
enforced  at  the  granularity  of  a 
user/object/program  triple  appears  to  be 
inadequately  addressed.  Lee's  work  and  mine 
are  independent:  drafts  of  both  papers 
were  presented  concurrently  as  position 
papers  at  the  invitational  Workshop  on 
Integrity  Policies  for  Commercial 
Information  Systems  held  at  Bentley 
College,  Waltham,  Mass.  The  notion  of  what 
Lae  calls  a  partially  trusted  subject  upon 
which  both  of  our  systems  depend  is 
original  with  neither  Lee  nor  myself:  it 
is  discussed  by  Schell  et  al.  in  [9]  and  by 
Bell  [10]  as  a  part  of  this  "updated" 
version  of  the  Bell  and  LaPadula  model. 

Also  noteworthy  is  a  recent  paper  by  Karger 
[11]  that  provides  a  capability-oriented 
perspective  on  the  Clark/Wilson 
requirements  and  raises  a  number  of 
interesting  design  and  implementation 
issues,  as  well  as  featuring  a  review  of 
background  papers  and  reports  more 
extensive  than  that  given  here. 
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1 . 3  Overview 

This  paper  provides  an  overview  of  the 
basic  construction  that  I  have  defined  for 
translating  an  arbitrary  abstract  system 
meeting  the  Clark/Wilson  requirements  into 
an  equivalent  system  based  upon  a  label- 
based  access  control  policy  with  integrity 
and  disclosure  categories  and  "partially 
trusted"  subjects.  Rather  than  presenting 
this  transformation  in  abstract 
mathematical  terms,  I  have  chosen  in  this 
paper  to  provide  a  more  understandable 
overview,  together  with  a  concrete  example. 
For  those  who  may  be  interested,  the  more 
abstract  (and  precise)  presentation  is 
available  as  a  Technical  Report  in  [12]. 

A  short  section  after  the  technical 
overview  addresses  the  ability  to  implement 


an  instance  of  the  transformation  using  a 
currently  available  TCB,  the  GEmini  Multi¬ 
processing  Secure  Operating  System  (GEMSOS). 

2.  Technical  Summary 

In  this  section,  I  will  first  review 
selected  technical  capabilities  provided  by 
a  typical  oommercially-available  TCB 
(GEMSOS)  that  will  be  important  in 
constructing  the  transformation  from  a 
Clark/Wilson  set  of  access  control 
requirements  to  an  equivalent  sot  of  policy 
requirements,  stated  in  terms  of 
discretionary,  non-discretionary ,  and 
application  policy  controls.  (I  have 
chosen  to  use  the  term  "non-discretionary 
access  controls"  in  place  of  the  usual 
"mandatory  access  controls",  as  originally 
defined  by  Salzer  and  Schroeder  [13],  in 
order  to  avoid  Clark  and  Wilson's  complaint 
that  the  use  of  the  term  "mandatory"  can  be 
confusing  to  those  unfamiliar  with  the 
jargon  of  the  Trusted  Computing  Base 
technical  community. )  It  should  similarly 
be  understood  that  by  identifying  certain 
of  the  controls  described  in  the  system 
below  as  "discretionary",  I  mean  simply 
that  the  control  is  based  on  an  individual 
user  identifier  (as  opposed  to  an  access 
class  or  clearance)  and  represents  an 
authorization  for  that  individual  user  to 
perform  some  security-relevant  action 
( j.-epresented  by  access  to  a  directly  or 
interpretively  accessible  object.) 

In  order  to  illustrate  the  system 
concretely,  I  will  develop  a  “toy"  system 
as  the  summary  proceeds.  We  will  imagine  a 
system  comprised  of  four  data  types,  A,  B, 

C,  and  D,  v/ith  each  data  typo  comprised  of 
an  indefinite  number  of  distinct  data 
objects.  (For  example,  data  type  A  might 
include  data  objects  Al,  A2,  A3,  etc.)  We 
will  suppose  that  there  are  defined  three 
transactions  that  transform  data  from  one 
type  to  another:  AtoB ,  BtoC,  and  BtoD.  We 
will  also  suppose  that  there  is  defined  a 
verification  procedure  ValidataAB  that 
determines  whether  the  objects  of  type  A 
and  B  are  mutually  consistent  (without 
modifying  them).  (These  transactions  are 
simply  executable  programs. )  The  example 
will  be  extended  as  needed  below. 


2.1  Kon-Dlscretlonary  Mechanisms 

The  purpose  of  this  section  is  to  review 
the  mechanisms  assumed  available  for  the 
enforcement  of  the  non-discretionary 
components  of  the  policy  and  their 
application  in  terms  of  a  strongly-typed, 
transaction-oriented  system  such  as  that 
described  by  Clark  end  Wilson.  It  is 
assumed  that  the  system  is  comprised  of 
objects  (passive  information  repositories) 
and  subjects  (active  entities  that  cpn  read 
and/or  write  objects.)  It  Js  important  to 
note  that  we  distinguish  between  a  program 
(which  is  an  object)  end  a  subject  (which 
is  typically  a  program  in  execution,  acting 
on  behalf  of  a  particular  user).  The 
abstraction  of  a  subject  is  implemented  by 
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the  security  kernel.  The  distinction 
between  a  program  and  a  subject  is 
important  because  the  single  label  on  a 
program  represents  its  sensitivity  as  a 
data  repository,  while  the  pair  of  labels 
(explained  later)  on  a  subject,  which  are 
related  only  incidentally  to  the  label  on 
the  program  it  is  executing,  represents  the 
accesses  allowed  to  the  subject. 

It  is  similarly  important  to  distinguish 
between  the  notion  of  a  subject  and  of  a 
user.  A  subject  is  an  entity  internal  to 
the  computer  system,  which  executes  on 
behalf  of  a  user  (who  is  external  to  the 
computer  system).  Again,  the  distinction 
will  be  important  because  a  given  subject 
may  well  have  a  pair  of  labels  only 
incidentally  related  to  the  user's 
clearance. 

The  set  of  all  possible  access  classes 
forms  a  lattice  --  mathematically,  a  set  of 
labels  with  a  dominance  relation  that 
partially  orders  them,  such  that  least 
upper  and  greatest  lower  bounds  are 
uniquely  defined.  (It  may  be  observed  that 
when  integrity  and/or  disclosure  categories 
exist,  it  is  not  necessary  for  all  possible 
combinations  of  the  categories  to  be 
defined  in  the  set  of  labels  to  have  a 
lattice  --  a  lattice  that  includes  all 
possible  combinations  is  called  a 
distributive  lattice  [14].  Of  importance 
in  this  paper  is  that  the  lattice  is  built 
from  two  essentially  independent 
components:  every  label  represents  a 
sensitivity  with  respect  to  disclosure,  and 
an  independent  component  representing  a 
sensitivity  with  respect  to  modification. 
Because  these  components  are  mathematically 
independent,  we  are  able  (in  effect)  to 
give  each  object  (including  programs) 
independent  labols  with  regard  to  its 
disclosure  and  integrity  sensitivities, 
give  users  independent  clearances  with 
respect  to  disclosure  and  integrity, 
and  give  subjects  (programs  in  execution) 
independent  authorizations  with  respect  to 
read  and  write  access. 

Both  the  disclosure  and  Biba  integrity 
components  of  a  label  may  generally  contain 
hierarchical  levels  and  non-hierarchical 
categories.  As  it  turns  out,  non- 
hierarchical  categories  alone  are 
sufficient  to  implement  the  desired  non- 
discretionary  component  of  a  Clark/Wilson 
policy.  The  following  notation  will  be 
used  to  represent  an  arbitrary  set  of 
integrity  and  disclosure  categories: 

[a,  b,  c,  .  .  .](x,  y,  z  .  .  .} 

is  that  unique  access  class  composed  of 
integrity  categories  a,  b,  c,  and  so  on, 
together  with  secrecy  categories  x,  y,  z, 
and  so  on.  Thus,  square  brackets  are  used 
for  a  set  of  integrity  categories,  and 
curly  braces  for  a  set  of  disclosure 
categories.  For  arbitrary  access  classes, 
these  sets  may  overlap. 

For  access  classes  composed  of  sets  of 
integrity  and  disclosure  categories  alone. 


the  dominance  relation  is  simplified  to  the 
following:  access  class  A  dominates  access 

class  B  if,  and  only  if,  the  disclosure 
categories  of  A  are  a  superset  (proper  or 
improper)  of  the  disclosure  categories  of 

B,  and  the  integrity  categories  of  A  are  a 
subset  (proper  or  improper)  of  the 
integrity  categories  of  B. 

Intuitively,  a  system  of  strongly  typed 
objects  may  be  constructed  as  follows: 
each  data  type  is  represented  by  an 
integrity  category  reserved  for  that  type, 
(used  to  limit  the  subjects  that  will  be 
allowed  to  modify  objects  of  that  type)  and 
by  a  disclosure  category  reserved  for  that 
type  (used  to  limit  the  subjects  that  will 
be  allowed  to  observe  objects  of  that 
type). 

For  our  example  system,  the  access  class 
labels  reserved  for  objects  of  type  A,  B, 

C,  and  D  are  [a][a],  [b][b},  [c]{c),  and 
[d][d),  respectively. 

Program  objects  are  given  special 
treatment.  Because  we  wish  to  control  the 
ability  to  execute  transactions  to  the 
granularity  of  o  single  certified 
transaction,  each  tx-ansaction  object 
(program)  will  ba  assigned  an  individual 
data  type  of  its  own.  In  addition,  we  will 
indicate  that  a  transaction  is  certified  to 
operate  upon  objects  of  a  particular  data 
type  by  including  the  integrity  category 
for  that  data  type  in  the  access  class  of 
the  transaction  object. 

For  our  example,  cert) tied  program  AtoB  is 
certified  to  operate  (either  by  reading, 
writing,  or  both)  or.  objects  of  types  A  and 
B.  Xn  addition  to  the  unique  transaction 
categories  tl  reserved  for  it,  we  add  the 
integrity  categories  for  both  A  and  B  to 
the  access  class  for  the  object  containing 
this  program:  viz.,  [ tl , a, b] { tl } . 

Similarly,  BtoC  would  have  access  class 
[t2,b,c] [t2] ,  BtoD  would  have  access  class 
[  t3, b,  dj  [t3 } ,  and  Vali.dateAB  would  have 
access  class  [ c4, a, b] [ t4 } . 

It  may  appoar  surprising  that  the  program 
far  a  transaction  is  given  an  integrity 
category  for  a  data  type  it  only  needs  to 
read.  However,  a  read,  in  a  real  computer 
system,  is  useful  only  if  the  read  allows 
a  copy  to  be  made  of  the  data  value  (e.g., 
as  a  return  value  in  a  subject's  stack.) 
This  copy  must  be  protected  as  having 
the  same  integrity  as  the  original: 
therefore,  in  order  to  work,  the  program 
(when  executed)  must  bo  able  to  write 
information  (in  order  to  make  copies)  of 
any  integrity  category  it  is  required 
to  read.  It  follows  that  the  program 
itself  must  also  be  certified  to  write 
information  of  this  integrity. 

Subjects  are  given  two  labels,  called  the 
write  label  and  the  read  label,  one  of 
which  (the  write  label)  serves  to  prevent 
the  subject  from  writing  objects  of  an 
unauthorized  type,  and  the  other  (the  read 
label)  from  reading  objects  of  an 
unauthorized  type.  The  precise  rules 
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enforced  are  as  follows:  a  subject  will  be 
allowed  to  write  an  object  only  if  the 
write  label  of  the  subject  is 
mathematically  dominated  by  the  label  of 
the  object,  and  will  be  allowed  to  read  an 
object  only  if  the  read  label  of  the 
subject  mathematically  dominates  the  label 
of  the  object. 

The  reader  may  justifiably  find  it 
difficult  to  apply  these  rules  when  both 
disclosure  and  integrity  categories  are  in 
use,  particularly  as  the  mathematical 
definition  of  dominance  is  abstract.  In 
more  intuitive  terms,  a  subject  may  only 
write  objects  that  have  all  of  the  secrecy 
categories  in  the  subjects  read  label  (or 
more)  --  no  write  down  with  respect  to 
disclosure.  A  subject  may  also  only  write 
objects  that  have  no  more  integrity 
categories  than  the  subject's  read  label  — 
no  write  up  in  integrity.  The  subject 
similarly  may  not  read  up  in  secrecy  or 
read  down  in  integrity.  The  abstract 
mathematical  detinitions  callow  the  security 
kernel  to  enforce  all  four  of  those 
constraints  by  encoding  them  in  two  subject 
labels  and  one  object  label. 

In  order  to  capture  the  notion  of 
strongly-typed  objects,  it  turns  out  that 
the  appropriate  format  for  the  write  label 
of  a  subject  is  the  sat  of  all  integrity 
Categories  for  the  data  types  it  is 
certified  to  read  and/or  write,  while  the 
form  of  the  read  label  is  the  sot  of  all 
disclosure  categories  for  these  data  types, 
together  with  the  disclosure  category  for 
the  transaction  to  be  executable.  (For  our 
system,  a  subject  must  usually  be  confined 
to  execute  a  single  transaction  in  order  to 
successfully  be  created. ) 

For  our  example  (without  knowing  anything 
about  user  clearances  yet)  wo  suppose  that 
snmo  subject  must  bo  created  to  execute 
transaction  AtoB .  The  indicated  write  and 
read  labels  for  such  a  subject  would  then 
be  [a,b]  for  the  write  label,  and  (a,b,tl) 
for  the  read  label. 

It  should  be  observed  that  relative  to 
objects  with  an  assigned  type,  the  labels 
on  the  subject  correctly  and  precisely 
constrain  it  to  manipulate  data  objects  of 
the  desired  type  only.  For  example,  an 
object  of  type  D,  with  label  [d]{d},  cannot 
be  read,  because  [d]{dj  is  not  dominated  by 
the  subject's  read  label  {a, b, c, tl , t2) . 
Similarly,  the  object  [d]{d)  cannot  be 
modified  by  this  subject  bscause  it  does 
not  dominate  the  subject's,  write  label, 
[a,b,c].  Finally,  transaction  t2  cannot  bo 
executed  by  this  subject  (for  example), 
because  it  will  not  be  allowed  to  read  or 
execute  an  object  with  disclosure  category 
(t2). 

An  important  observation  is  that  a  subject 
labeled  as  described  is  "partially  trusted" 
in  that  it  may  bo  able  to  write  objects  of 
different  access  classes,  and  may  be  able 
to  write  objects  of  an  access  class  not 
dominating  the  access  class  of  some  object 


it  can  read.  Therefore,  it  is  important 
that  the  subject  be  limited  to  execute  only 
those  transactions  certified  to  perform  the 
type  conversions  it  might  be  able  to  make. 
The  program  integrity  rule,  however, 
guarantees  that  this  will  be  the  case.  The 
program  integrity  rule  requires  that  any 
program  executed  by  a  subject  have  an 
access  class  with  integrity  categories  that 
include  all  of  the  integrity  categories  of 
the  subject's  write  label.  (It  may  have 
more).  This  rule  has  a  relatively 
intuitive  interpretation  in  the  context  of 
strong  typing:  program  integrity 
guarantees  ( as  enforced  by  the  security 
kernel)  that  a  subject  may  only  execute 
transactions  that  have  been  certified  to 
operate  correctly  against  all  of  the  data 
types  for  data  objects  the  subject  is 
allowed  to  access.  That  is,  enforcement  of 
program  integrity  by  the  kernel  means 
globally  that  every  transaction  that  is 
executed  will  bo  certified  to  be  executable 
against  any  of  the  typed  objects  accessed 
--  exactly  what  is  wanted  for  any  strongly 
typed  system,  including  Clark/Wilson. 

Users  (who  are  distinct  from  subjects)  are 
given  a  clearance  that  reflects  their 
authorization  to  manipulate  data  of  a  given 
type  by  placing  both  its  disclosure  and 
modification  categories  in  the  user's 
clearance.  Furthermore,  a  user  is  given 
authorization  to  execute  a  particular 
transaction  by  placing  its  disclosure 
category  in  the  user '3  clearance.  It  is 
sufficient  that  the  TCD  constrain  the  read 
and  write  labels  of  a  subject,  executed  on 
behalf  of  an  authenticated  user,  to  have  a 
write  class  that  is  some  subset  of  tho 
user's  integrity  categories,  and  a  read 
class  that  is  some  subset  of  the  user's 
disclosure  categories.  A  subject  oboying 
this  constraint  will  either  have  no 
transaction  executable  (i.e.,  the  attempt 
to  create  the  subject  by  the  TCB  aborts) 
or  will  end  up  executing  a  single 
transaction,  authorized  to  the  user, 
against  objects  of  data  typos  authorized  to 
the  user.  As  discussed  above,  program 
integrity  guarantees  that  such  a 
transaction  will  also  be  one  that  has  been 
certified  to  operate  on  objects  of  tho 
given  type. 

It  is  worth  noting  that  although  a 
transaction  might  be  certified  to  operate 
on  a  variety  of  types  (e.g..  A,  B,  and  C), 
an  individual  user  might  be  authorized  only 
to  operate  on  a  subset  of  these  types 
(e.g.,  A  and  B).  In  such  a  case,  the  user 
will  not  be  able  to  create  a  subject 
executing  the  transaction  against  an  object 
of  the  forbidden  type,  even  though  the 
transaction  itself  is  certified  to  do  so. 
Many  existing  systems  based  upon  granting 
access  to  "canned  transactions"  are  unable 
to  limit  the  authorizations  independently 
for  different  users  cf  the  same 
transaction.  If  a  user  has  access  to  a 
transaction,  the  user  “inherits"  any 
authorizations  the  transaction  may  have. 
(The  "setuid"  feature  provided  by  UNIX 
works  this  way,  for  example.) 
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In  contrast,  the  system  described  here 
allows  the  authorizations  of  different 
users  to  be  controlled  independently  of  the 
certifications  recorded  for  each 
transaction.  Thus,  the  certifying  official 
(for  transactions)  need  only  concentrate  on 
determining  what  a  transaction  is  trusted 
to  do  correctly  in  selecting  a  label  for 
the  transaction,  while  the  security 
administrator  controls  access  by  individual 
users  to  particular  transactions  and  object 
types  without,  (in  theory),  needing  to 
consider  the  certification  a  transaction 
has  gained.  If  an  attempt  is  made  to  give 
a  subject  "too  much  authority"  with  respect 
to  the  actual  certification  recorded  for  a 
transaction,  the  TCB,  enforcing  program 
integrity,  will  abort  the  subject  before  it 
begins  because  the  transaction  will  be 
unexecutable. 

2 . 2  Discretionary  Mechanisms 

The  system  summarized  above  does  not  yet 
capture  the  complete  intent  of  the 
Clark/Wilson  requirements  with  respect  to 
access  control.  It  might  be  characterized 
as  "strong  typing,  11  with  users  cleared  to 
execute  particular  transactions  and 
(independently)  to  access  objects  of 
particular  types.  Clark  and  Wilson  ask, 
in  particular,  for  controls  on  which 
transactions  a  user  can  execute  against 
which  objects:  that  is,  permission  to 
access  object  A  and  to  execute  transaction 

T,  should  not  automatically  imply 
permission  to  execute  T  against  A,  even  if 
T  is  certified  for  A. 

In  particular,  Clark  and  Wilson  require 
that  the  TCB  maintain  (either  implicitly  or 
explicitly),  a  list  of  relations  listing 
authorized  combinations  of  users, 
transactions,  and  objects  (or  data  types). 
It  is  important  to  see  how  the  system 
described  so  far  does  not  meet  this 
requirement . 

In  more  complex  systems  than  our  example, 
it  becomes  possible,  if  there  are  no 
additional  controls,  to  implicitly  clear  a 
user  for  an  undesired  transaction  in  order 
to  make  some  combination  of  desired 
transactions  available.  Suppose,  for 
example,  that  there  are  four  data  types  (A, 

U,  C,  D),  and  two  certified  transactions, 
both  "query"  transactions,  each  certified 
to  operate  correctly  on  each  of  the  data 
types.  (Wo  might  imagine,  for  instance, 
that  A,  B,  C,  and  D  are  disjoint 
collections  of  personnel  records  for  four 
different  divisions,  tl  is  a  transaction 
for  observing  salaries,  and  t2  a 
transaction  for  observing  training 
qualifications. ) 

We  wish  to  give  a  particular  user  the 
authority  to  observe  salaries  in  database  A 
only,  and  training  qualifications  in  any  of 
the  databases.  In  the  system  so  far 
described,  there  is  no  way  to  do  this 
witl.out  granting  too  much  authorization, 
in  order  to  make  transaction  tl  executable 
against  A  for  the  user,  we  must  add 


{tl,a}[a]  to  the  user's  clearance.  In 
order  to  make  transaction  t2  executable 
against  A,  B,  C,  and  D,  we  must  add 
{ t2,  a ,  b,  c,  d}  [a, b,  c,  d]  to  the  user’s 
clearance.  The  user's  single  composite 
clearance  is  now  {tl , t2, a, b, c, d} [a, b, c, d] 
and  nothing  prevents  the  user  from 
executing  either  transaction  against  any  of 
.ne  data  objects. 

It  can  be  argued  that  by  restructuring  the 
transactions  and  repartitioning  the  data, 
the  desired  effect  could  be  attained. 

While  this  is  true,  it  is  hardly  convenient 
or  practical  to  have  to  repackage  either 
transactions  or  data  types  in  reaction  to 
the  addition  of  new  users  with  novel 
clearances.  In  this  matter,  I  concur 
whole-heartedly  with  Clark  and  Wilson:  the 
maintenance  of  a  table  of  relations  between 
permitted  user /'transact ion/object 
combinations  (however  it  may  be  stored 
physically)  is  a  practical  necessity. 

The  approach  I  endorse  is  to  treat  the 
table  of  triples  as  a  special  form  of 
discretionary  controls  maintained  within 
the  TCB.  When  a  request  is  made  to  the  TCB 
to  create  a  now  subject,  this  table  will  be 
consulted  to  determine  whether  the  new 
subject  is  permitted.  Sufficient 
information  to  do  this  is  encoded  in  the 
requested  read  and  write  labels  for  the 
subject  (plus  the  user  identity,  maintained 
within  the  TCB)  if  only  single-transaction 
subjects  are  allowed:  the  integrity 
category  for  the  subject,  plus  any  data 
types  accessed,  is  included  in  the  write 
label  requested  for  the  subject. 

I  have  preferred  to  separate  this  control 
from  the  underlying  non-discretionary 
controls  for  the  following  reasons: 

•  it  would  appear  that  the  control  is 

intrinsically  discretionary  in  nature: 
it  is  based  (in  part)  on  the  actual 
user  identity  (not  a  clearance).  The 
notion  of  the  non-discretionary 
component  of  the  system  is  that  users 
are  cleared  to  execute  transactions 
and  access  data  objects  on  a  long-term 
basis:  this  is  refined  by  a 

discretionary  control  granting  access 
to  particular  combinations  of 
transactions  and  objects  on  a  more 
volatile  basis. 

•  it  should  not  be  assumed  that  the 
mechanism  is  vulnerable  simply  because 
I  have  called  it  a  "discretionary" 
mechani  sir,,  any  more  so  than  the 
management  of  group  memberships  ( for 
example)  is  vulnerable.  It  would  be 
possible,  for  instance,  to  make  the 
table  of  relations  modifiable  only  by 
a  designated  security  administrator 
via  a  trusted  TCB  interface. 

•  the  decomposition  into  three  related, 
but  distinct  sets  of  controls 
(certification  of  transactions, 
clearance  of  users,  and  authorization 
by  means  of  relations)  would  appear  to 
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simplify  the  problem  of  keeping 
everything  straight.  In  particular, 
the  certification  of  transactions 
would  depend  only  upon  their 
correctness  (the  certifier  does  not 
need  to  be  concerned  with  the  impact 
of  a  change  in  certification  on  user 
authorizations);  the  clearance  of 
users  I  view  as  establishing  long-term 
"damage  control"  boundaries,  while  the 
authorization  of  users  to  execute 
transactions  against  particular 
objects  or  data  types  in  the  relation 
table  establishes  a  shorter-term  "need 
to  do". 

•  It  should  be  understood  that  in  order 
for  execution  of  a  transaction  to 
commence,  several  things  must  match: 

1)  the  transaction  must  be  certified 
for  execution  against  the  selected 
data  types,  2)  the  user  must  have  a 
basic  clearance  both  to  access  the 
data  types,  and  to  execute  that 
transaction,  3)  specific  authorization 
in  the  relation  table  must  exist  for 
the  user  to  execute  the  transaction 
against  these  specific  objects.  If 
any  of  these  conditions  fail,  the 
transaction  cannot  begin. 


3.  Application  to  the  Clark/Wilson 
He  SLlirei njjs 

In  the  previous  section,  the  emphasis  was 
on  presenting  an  overview  of  how  the 
proposed  system  is  to  work.  In  this 
section,  the  requirements  stated  by  Clark 
and  Wilson  in  [1]  aid  restated,  with  a 
short  summary  of  how  they  are  mapped  into 
the  proposed  system. 

3,1  Do  fin i tions 

•  Constrained  Data  Item  (CDI)  --  those 
data  items  within  the  system  to  which 
tha  integrity  policy  must  be  applied. 

A  CDI  corresponds  to  what  has  been 
called  a  data  type  in  the  preceding 
section.  Note  that  a  CDI  may  consist 
of  many  distinct  objects,  or,  for 
important  data  objects,  an  object  may 
be  given  a  unique  typo:  it  is  up  to 
1:ho  application  designer. 

•  integrity  Verification  Procedure  (IVP) 
--  a  procedure,  the  purpose  of  which 
is  to  confirm  that  all  of  the  CDI's  in 
the  system  conform  to  the  integrity 
specification  at  the  time  the  iVP  is 
executed.  *•-  In  my  system  the  IVP,  as 
designed,  would  be  a  transaction 
object  certified  to  correctly  perform 
the  verification  function  over  all 
represented  data  types.  Note  that  my 
system  also  accommodates  "smaller" 
IVP-like  transactions  for  arbitrary 
subsets  of  the  data  types. 

•  Transformation  Procedure  (TP)  --  a 

well-formed  transaction  that  changes 
the  set  of  CDIs  from  one  valid  state 
to  another.  --  In  my  system,  a  TP  is 


an  arbitrary  transaction  object 
(program)  that  has  been  certified  to 
operate  correctly  on  its  designated 
data  types. 

•  Unconstrained  Data  Item  (UDI)  --  a 
data  item  not  covered  by  the  integrity 
policy.  --  In  my  system,  a  data  type 
would  be  reserved  for  UDIs.  Those 
TP's  certified  to  correctly  transform 
UDIs  to  CDIs  (i.e.,  validate  and  move 
data  into  the  system)  would  simply 
have  the  integrity  and  disclosure 
categories  for  the  UDI  data  type  added 
to  their  access  class. 

3 . 2  Enforcement  Rules 

•  Cl:  All  IVPs  must  properly  ensure  that 
all  CDIs  are  in  a  valid  state  at  the 
time  the  IVP  is  run.  --  Clark  and 
Wilson  identify  this  as  a  requirement 
imposed  upon  the  certifier  of  the  IVP, 
as  it  would  be  in  the  system  I  have 
described. 

•  C2:  All  TPs  must  be  certified  to  be 
valid.  .  .  For  oach  TP,  the  certifier 
must  specify  a  list  of  CDIs  (called 

a  relation)  which  the  TP  has  been 
certified  to  manipulate  correctly. 

--  In  the  system  described,  this 
list  is  ombodded  in  the  access 
class  assignod  to  the  TP  program 
object. 

»  El:  the  system  must  maintain  the 
relation  referred  to  in  rule  C2,  and 
must  ensure  that  the  only  manipulation 
of  any  CDI  is  by  a  TP,  for  which  the 
CDI  occurs  in  tho  relation  for  that 
TP.  --  This  rule  is  enforced 
indirectly  by  means  of  program 
integrity.  The  security  kernel 
ensures  by  means  of  this  constraint 
that  the  TP  executed  by  a  subject  is 
certified  for  all  CDI's  accessible  by 
the  subject.  It  follows  that  any  CDI 
manipulated  by  a  TP  in  execution  is 
one  that  the  TP  Is  certified  to 
manipulate  corroctly. 

•  E2:  the  system  must  maintain  a  list  of 
relations  associating  triples  of  the 
form  <UserID,  TP,  CDI>  that  identifies 
which  users  may  cause  which  TPs  to  be 
executed  to  manipulate  which  CDIs. 

as  discussed  in  the  last  section,  this 
rule  is  enforced  explicitly  by  the  TC8 
as  a  discretionary  policy.  However, 
it  is  backed  up  by  the  additional 
requirement  that  the  user  be  cleared 
for  a  given  TP  and  list  of  CDIs  in  the 
non-discretionary  sense. 

•  C3:  the  list  of  relations  in  E2  must 
be  certified  to  meet  the  separation  of 
duty  requirement.  --  Clark  and  Wilson 
identify  this  as  a  rulo  to  be  enforced 
by  the  human  administrators  of  the 
system. 

•  E3:  the  system  must  authenticate  the 
identity  of  each  user  attempting  to 
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execute  a  TP.  --  as  this  is  a 
commonly  met  requirement  for  any 
high-assurance  evaluated  TCB,  it  would 
seam  unnecessary  to  address  this 
requirement  in  any  detail. 

•  C4:  all  TPs  must  be  certified  to  write 
to  an  append-only  CDI  (the  log)  all 
information  necessary  to  permit  the 
nature  of  the  operation  to  be 
reconstructed.  --  It  might  be  noted 
that  this  is  presented  by  Clark  and 
Wilson  as  an  application-dependent 
requirement,  requiring  review  of  the 
TP  by  the  certifier.  However,  the 
intent  of  this  requirement  would  be 
met  in  part  by  the  security  audit 
function  of  the  underlying  TCB,  which 
would  record,  as  a  security-ralevant 
event,  the  creation  of  a  new  subject, 
its  associated  user  and  access  classes 
in  the  security  audit  log. 

•  C5:  any  TP  that  takes  a  UDI  as  an 
input  value  must  be  certified  to 
perform  only  valid  transformations,  or 
else  rio  transformations,  for  any 
possible  value  of  the  UDI.  — 
Enforcement  of  this  rule  is  also  the 
province  of  tho  certifiers:  the 
described  system  provides  a  means, 
however,  for  ensuring  that  a  TP  not 
certified  to  take  a  UDI  as  input  in 
fact,  cannot  be  executed  with  raad 
access  to  a  UDI. 

•  E4:  only  the  agent  permitted  to 
certify  entities  may  change  the  list 
of  Buch  entities  associated  with  other 
entities:  specifically,  those 
associated  with  a  TP.  An  agent  that 
can  certify  an  entity  may  not  have  any 
execute  rights  with  respect  to  that 
entity.  --  This  rule  is  to  be  enforced 
in  several  parts  (outside  the  security 
kernel).  First  of  all,  in  order  to 
"certify"  a  TP  one  must  be  able  to 
create  a  subject  with  a  write  label 
containing  the  integrity  category  [tn] 
rsBarved  for  that  TP.  It  follows  that 
a  user  with  a  clearance  containing 
{tn}[tn]  is  a  "certifier"  for  the  TP. 
In  order  to  execute  the  TP  against  a 
data  type  A,  a  user's  clearance  must 
contain  (tn,a}[a].  Thus,  there  exists 
a  clear-cut  way  to  distinguish 
"certifiers"  from  "users"  of  a  TP: 
only  certifiers  have  a  clearance 
containing  [tn).  The  rule  that  must 
be  enforced  by  the  TCB  can  than  be 
restated  ae  follows:  no  individual 
may  be  given  a  clearance  that 
simultaneously  contains  the  integrity 
category  for  a  transaction  and  the 
integrity  and/or  secrecy  category  of 
any  data  type  contained  in  the  label 
for  tho  transaction  object.  This  rule 
would  be  most  easily  enforced  by  the 
TCB  the  time  some  user  was  given  a 
clearance  as  a  "certifier"  by  ensuring 
that  tho  user  was  cleared  for  none  of 
the  reserved  proposed  for  it  oy  the 
"certifying"  individual). 


4.  Prospects  for  a  Near-Term 
Implementation 

In  the  material  presented  above,  I  have 
described  the  proposed  system  for 
supporting  the  Clark/Wilaon  requirements  in 
the  simplest  mathematical  terms  I  could 
find:  the  emphasis  was  on  making  a  rather 
complex  construction  as  clearly  explained 
as  possible  without  becoming  mired  in 
extraneous  design  issues.  In  particular, 
neither  the  efficiency  nor  the  prospects 
for  actually  building  the  proposed  system 
were  considered.  The  purpose  of  this 
section  is  to  address  these  issues  briefly. 

We  might  first  list  some  of  the 
characteristics  a  conventional  TCB  with  a 
non-discretionary  security  kernel  should 
have  in  order  to  support  tho  construction 
given  above: 

e  it  should  support  both  disclosure  and 
Biba  integrity  policies; 

*  it  should  support  partially  trusted 
subjects  with  both  write  and  read 
labels; 

•  it  should  support  both  hierarchical 
and  non-hierarchical  access  classes; 

*  it  should  enforce  a  program  integrity 
policy; 

•  it  should  be  subsetted  in  such  a  way 
that  the  special  requirements  of  the 
Clark/Wilson  policy  for  constraining 
clearances  and  imposing  controls  on 
the  creation  of  new  subjects  based  on 
<Userld,  TP,  CDI>  tx'iples  can  bo 
introduced  without  disturbing  the 
security  kernel  itself. 

The  GEMSOS  TCB  has  all  of  these  properties. 
One  issue  raised  by  Karger  in  [11]  is  worth 
special  mention:  it  should  be  apparent 
that  a  relatively  large  number  of  integrity 
and  disclosure  categories  will  be  needed 
for  a  practical  system.  GEMSOS  supports  an 
access  class  label  with  over  90  bits 
available  to  represent  the  lattice  of 
aocess  classes.  The  commercial  version  of 
this  system  uses  these  bits  to  represent  a 
distributed  lattice  conformant  to  the 
guidelines  in  [3] .  However,  the 
interpretation  of  these  bits  is  confined 
internally  to  a  single  module  which  is 
easily  modified.  In  order  to  support  a 
Clark/Wilson  policy  (as  only  limited 
combinations  of  the  categories  will 
actually  occur)  this  module  can  relatively 
easily  be  restructured  to  encode  a  much 
higher  number  of  "data  types".  The 
remainder  of  the  kernel  depends,  for  its 
correct  operation,  only  upon  the  fact  that 
the  policy  is  a  lattice.  (In  particular, 
non-distributive  lattices  are 
accommodated.)  Thus,  making  the  required 
modification  to  the  kernel  is  an  issue 
primarily  of  routine  software  engineering. 

The  following  changes,  all  relatively 
minor,  would  be  needed  to  convert  the 
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GEMSOS  TCB  into  ona  supporting  a 
Clark/Wilson  policy  in  a  practical  way: 

•  the  internal  module  interpreting 
access  class  labels  would  need  to  be 
modified,  as  discussed  above; 

m  additions  would  have  to  be  designed 
and  coded  for  the  discretionary  access 
control  manager  to  enforce  the 
additional  requirement  to  constrain 
subject  creation  based  on  a  table  of 
"triples".  These  would  not  disturb 
the  existing  discretionary  and/or 
non-discretionary  controls,  but  serve 
as  a  refinement  to  them. 

*  additions  would  have  to  be  designed 
and  coded  to  enforce  rule  E4. 

All  of  these  changes  are  relatively  minor. 
Although  a  re-evaluation  of  the  TCB  would 
bo  induced,  existing  evidence  could  be 
substantially  re-used.  In  particular, 
because  of  the  high  degree  of  structure  in 
the  existing  GEMSOS  design,  and  because  no 
fundamental  changes  would  be  required  to 
the  design,  the  magnitude  of  effort 
required  for  such  a  re-evaluation  would  be 
lew,  and  the  risk  of  failure  small. 

A  final  point  worth  noting  is  that 
mathematically  (and  practically,  aa  well) 
it  is  relatively  easy  to  define  a  lattice 
that  combines  the  lattice  of  "types"  with 
conventional  disclosure  and  integrity 
lattices  (using  the  Cartesian  product.)  It 
follows  that  a  policy  combining  the 
military  and  strongly-typed  systems  is 
immediately  foasible. 

5 .  Conclusions 

In  this  paper  I  have  presented  a 
construction  that  maps  an  arbitrary 
Clark/Wilson  policy  to  an  equivalent 
"military"  policy  containing  both  non- 
discretionary  arid  discretionary  components. 
In  particular,  the  most  important  elements 
of  the  Clark/Wilson  requirements  (execution 
of  TPs  only  against  CDIs  they  are  certifiod 
for,  and  only  by  users  authorized  to 
execute  the  TP  against  these  CDIs)  can  be 
en'orced  with  the  strong  assurances 
traditionally  associated  with  non- 
discretionary  policies.  Moreover,  because 
this  construction  points  the  way  for 
utilizing  existing  technology,  the 
prospects  for  a  near-term  implementation  of 
a  highly-assured  Clark/Wilsor,  system  are 
promising. 

However,  this  construction  would  appear  to 
have  some  theoretical  interest  as  well. 
Essentially,  the  construction  shows  that  a 
security  kernel  supporting  Biba  integrity, 
with  both  hierarchical  and  non-hierarchical 
components,  and  enforcing  program 
integrity,  can  serve  as  a  strong  type 
manager.  As  it  would  appear  that  Boebert 
and  Kane  have  shown  that  the  inverse 
transformation  is  also  possible  --  a  strong 
type  manager  can  enforce  a  lattice  security 
policy  --  in  some  sense,  these  views  about 


integrity  are  two  different  ways  of  talking 
about  the  same  things.  Which  way  you 
select  depends  upon  the  things  you  want  to 
talk  about  --  a  "change  of  coordinates" 
into  the  other  system  is  always  possible. 
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ABSTRACT 

Currently,  an  important  concept  in  computer 
security  is  data  integrity.  As  early  as  1977,  there 
existed  formal  models  which  incorporated  integrity 
in  an  access  control  policy  [Biba],  In  1982  Goguen 
and  Meseguer  provided  the  modelling  wurld  with 
their  non-interference  theory  which  develops 
assertions  based  upon  pairs  of  users  [G  +  M], 
Furthermore  Clark  and  Wilson  [C+W]  discussed  the 
concept  of  data  integrity  and  the  differences  between 
an  integrity  policy  and  those  policies  controlling 
access  to  sensitive  information.  This  paper  takes 
advantage  of  the  flexibility  of  non-interference  to 
define  a  security  policy  for  data  integrity. 

Introduction 

A  major  concern  of  computer  security  is  the 
concept  of  data  integrity.  Integrity  considers  the 
ability  of  a  computer  system  to  assure  its  users  that 
the  information  it  Btores  is  not  corrupted.  This  is 
different  from  the  access  control  policies  [B  +  L]  used 
for  protecting  sensitive  information  which  have  been 
studied  intensely  for  the  paBt  decade.  Unlike  access 
control  policies  which  restrict  access  to  data  objects 
based  on  classification  and  clearances,  an  integrity 
policy  should  discuss  properties  of  the  system  which 
protect  the  soundness  and  completeness  of  the  stored 
information.  We  do  not  concern  ourselves  with  a 
discussion  of  the  differences  in  the  two  policies,  but 


this  point  is  clearly  brought  out  in  a  paper  by  David 
Clark  and  David  Wilson  [C  +  W],  However  we  use 
certain  of  the  concepts  from  their  paper  as 
motivation  for  our  integrity  policy  which  is 
expressed  in  non-interference  theory. 

l^ativation 

The  model  by  Clark  and  Wilson  [C  +  WJ 
consists  of  a  finite  state  machine  which  has  a  set  of 
constrained  data  items  (CDl'e)  representing  those 
elements  for  which  integrity  must  be  provided  and 
similarly  a  set  of  unconstrained  data  items  (UDI’s). 
Also  included  in  the  model  are  two  types  of 
procedures.  The  first  type  of  procedure  is  called  a 
Transformation  Procedure  (TP)  which  can  be  viewed 
as  the  typical  state  transition  functions.  The  second 
type  of  procedure  is  a  Integrity  Verification 
Procedure  (IVP),  whose  purpose  is  "to  confirm  that 
all  of  the  CDI’s  in  the  system  conform  to  the  integrity 
specification  at  the  time  the  IVP  is  executed."  [C  +  W 
p.189).  With  a  given  set  of  procedures,  they  also 
define  a  set  of  nine  rules,  partitioned  into 
certification  and  enforcement  rules,  to  which  the 
procedures  must  adhere  if  the  system  is  to  provide 
data  integrity. 
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A  koy  concept  described  by  those  rules  is  that  of 
separation  of  duty.  Separation  of  dutv  refers  to  a 
system  in  which  u  statu  transition  cannot  be  fully 
executed  by  one  user  but  requires  the  cooperation  of 
two  or  more  users  to  complete.  A  typical  example  of 
separation  of  duty  is  a  business  procurement  process. 
That  is,  one  user  requests  an  object,  another  user 
authorizes  the  request,  a  third  actually  purchases 
and  receives,  until  finally  the  original  user  who 
requested  the  object  receives  it,  In  this  example  a 
company  handling  multi -million  dollar  objects 
certainly  would  not  want  one  person  to  have  the 
capability  of  performing  all  the  functions  in  the 
procurement  process,  It  is  this  concept  of  separation 
of  duty  upon  which  we  will  build  uur  definition  of  un 
integrity  policy. 

Definitions 

Let  U  bo  the  set  of  ull  system  users  and  C  the 
set  of  state  changing  commands.  For  every  user  u  e 
U  let  uu  e  U  be  the  user  whu  is  designated  as  the 
"uuthorizer"  of  uny  command  issued  by  u. 
Informally,  uur  definition  of  an  integrity  preserving 
system  is  as  follows: 

l)of:  A  system  (finite  state  machine)  preserves 
integrity  provided  that  for  every  user  u  c  U  and 
command  c  c  C,  the  command  c,  when  issued  by  u 
does  not  effect  the  system  until  au  authorizes  c. 

The  phrase  "u  does  not  effect  the  system"  can 
be  restated  as  "whatever  u  does  is  not  visible  by  any 
other  user"  or,  better  yet  "u  does  not  interfere  with 
y"  where  v  e  U\{u,au}.  The  last  phrasing  indicates  a 
relation  to  non-interference  theory.  However  we  will 
see  that  the  clause  "until  au  authorizes  the 
command"  will  be  represented  in  a  definition  for  a 
purgeable  user-command  pair.  We  formalize  our 
definition  using  the  notation  of  Goguen  and 
Meseguer  in  [G  +  Mj.  Recall  that  w  is  a  finite 
sequence  of  user-command  pairs  w  = 
(ui,ci),(U2,C2),...,(un,cn)  where  u;  r.  U  and  ci  c  C.  The 
family  of  all  possible  input  sequences  is  denoted  by 
lUxC)*.  The  state  of  the  machine  determined  by  w 
from  the  universal  initial  stale  is  denoted  by  [[wj]. 


The  non-interference  assertion  that  we  develop  for 
integrity  differs  somewhat  from  the  assertions  that 
Goguen  and  Meseguer  created.  The  difference  lies  in 
the  definition  of  purgeability  of  a  user-command  pair 
which  in  turn  creates  u  difference  in  the  purge 
function. 

A  purging  function  is  the  key  tool  in 
formalizing  non-interference  assertions.  Given  a 
finite  sequence  of  user-command  pairs  w,  the  purge 
of  the  sequence  w  is  simply  a  certain  subsequence  of 
w.  In  our  case,  this  subsequence  of  w  is  the  one 
where  all  commands  issued  by  u  are  authorized. 
That  is,  uny  command  by  u  that  is  not  authorized  is 
deleted  (purged)  from  the  sequence  w.  Formally  we 
say: 

Dcf  1:  A  user  command  pair  (upci)  c  w  is  purgeable 
with  respect  to  u  iff  u  =  Uj  and  there  is  not  a  user- 
command  pair  (uj,0j)  t  w  with  Uj  =  uu  und  cj  = 
"authorization  command  for  u"  and  i  <  j. 

Using  this  definition  of  u  purgeable  user-command 
pair  we  got  a  recursive  definition  for  the  purge 
function: 

Def:  Let  w  --  (U|,ei),(U2,C2),...,(u„,cn).  Then  for  i  = 

1.2 . n  we  have  Purge^tUxC)*  =>  (UxC)*  where 

Purgeu(0)  =  0  and  Purgeu((ui,ci),...,(Un*Cn))  = 

I’urgou((ui+  i,C[+  i),...,(u„,e„)) 
if  luges)  is  purgeable  with  respect  to  u 

or 

(Ui,oi),l’urgou((u|  +  i,ct  +  i),...,(u„,c*„)) 
otherwise 

Informally  Purgeu(w)  will  delete  from  the 
sequence  w  any  command  issued  by  u  that  is  not 
later  authorized  by  au.  Notice  that  this  definition  of 
purging  is  different  from  the  purging  performed  in 
the  non-interference  definition  in  [G  +  M  p.79j. 
Their  purging  function  simply  removes  all  user 
command  pairs  issued  by  u  or  removes  those  where 
the  command  is  from  a  subset  of  C,  Our  definition  of 
purge  is  dependent  upon  the  rest  of  the  sequence  in 
determining  the  purgeability  of  a  u3er-eommand 
pair. 
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Even  though  the  defintion  nf'our  purge  function 
is  different  from  Goguen  and  Meseguer’s,  with  an 
extru  assumption  we  can  derive  u  purge  function 
which  performs  conditional  non-interference.  The 
assumption  is:  let  any  authorization  command 
issued  by  au  authorize  all  previous  commands  by  u. 
With  this  additional  hypothesis,  our  purge  function 
behaves  exactly  like  that  of  Goguen  and  Meseguer’s 
conditional  non-interference  purging.  Thut  is, 
Purgeu(w)  =  W[W2  where  w  -  wiWjji  and  wi  is  the 
longest  subsequence  of  w  which  ends  in  an 
authorization  command  and  w 2  =  Purgeu(W2i).  We 
will  discuss  more  aspects  of  purging  in  a  later 
section,  for  now  let  us  continue  with  our 
developement  of  dutu  integrity,  Given  the  above 
definitions  we  cun  state  the  following: 

Policy  1:  A  system  (finite  state  machine)  preserves 
integrity  provided  that  for  every  u  c  U  and  v  c 
U\{u,uu}  we  huve  u  does  not  interfere  with  v  modulo 
Purgeu  written 

u  :|  v  mod  Purgeu 

III 

out(Uw|i,v,r)  =  out([[Purgeu(w)]],v,r) 
for  all  we(UxC)+. 

Generalizations 

Upon  examination  of  the  above  definition, 
there  are  several  ways  one  could  generalize  to  allow 
more  flexibility.  Each  generalization  will  be 
summarized  by  stating  a  new  definition  for  the 
purgeability  of  a  user-command  pair  and  also  a 
revised  policy  statement.  The  purge  function  will 
also  be  different  but  that  is  implicit  because  of  the 
new  definition  of  purgeable.  We  have  ulready  stated 
•  generalization  earlier  with  the  assumption  that  all 
previous  commands  issued  by  u  can  be  authorized  by 
•u  with  a  single  command,  The  most  obvious  way  to 
generalize  is  to  say  that  more  than  one  user  needs  to 
authorize  a  command  issued  by  u.  Thut  is,  let 

=  j*  e  U  |  x  must  be  a  member  of  the 
authorization  process  for  u  }. 

We  postulate  that  the  memhers  of  the  authorization 
set  Au  constitute  a  tree  as  defined  in  digraph  theory. 


This  seems  to  be  a  natural  structure  to  impose  on  the 
set  because  of  the  management  hierarchy  which 
exists  in  the  corporate  world.  We  know  thBt  in  many 
instances  a  manager  will  not  grant  authorization  for 
an  action  until  various  subordinates  have  given 
their  approval.  This  concept  simply  says  that  there 
is  a  partial  ordering  on  the  set  Au-  Thus  Au 
determines  an  "authorization  tree  for  u”  with  the 
members  of  Au  as  the  nodes,  u  as  the  root,  and  u 
directed  edge  exists  from  u;  to  uj,  with  uj.Uj  r.  Au,  iff  uj 
follows  ui  in  the  authorization  process  for  u.  The 
example  below  will  help  to  illustrate  this  point. 

Ex;  Suppose  Paul,  whenever  he  wants  to  publish  u 
puper,  has  to  get  the  following  approvals; 
WilKtoehnieal  advisor),  Tedtdivision  chief), 
John(office  chief),  und  Eredfpatent  officer).  If  we 
assume  that  the  jobs  of  Will, Ted,  and  Fred  are 
independent  and  an  office  chief  is  above  u  division 
chief  in  the  corporate  architecture  then  ApUul  = 
{Will, Ted, John.Fred}  and  the  authorization  tree  for 
Paul  looks  like  Figure  1. 

John 


I 

Will  Ted  Fred 


Paul 
Figure  1 


Incorporating  A(1  into  our  integrity  concept  yields 
the  new  purgeable  definition  and  policy: 

I)ef  2:  A  user  command  pair  (Ui,c;)  c  w  is  purgeable 
with  respect  to  u  iff  u  =  u;  and  there  is  not  a 
subsequence  of  user-command  pairs  beginning  at 
<uj,ci)  which  define  the  authorization  tree  for  u. 

Policy  2:  A  system  (finite  state  machine)  preserves 
integrity  provided  that  for  every  u  e  U  and  v  c 
U\({u}UAu)  we  have  u  does  not  interfere  with  v 
modulo  Purgeu  written 
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u  v  mod  Purge,, 

III 

out(l[w)],v,r)  =  out(l[Purge„(w)]J,v,r) 
for  all  w  e  (UxC)*. 

Closely  related  to  the  previous  generalization 
is  the  capability  of  providing  "group"  integrity 
protection.  This  refers  to  allowing  individuals  to 
interact  with  each  other  without  worrying  about 
integrity,  in  other  words  interfering.  Groups  arise 
naturally  out  of  the  common  practice  of  partitioning 
a  project  among  several  people.  In  this  case  we 
would  want  all  the  people  on  the  same  project  to  be 
able  to  interact  freely  without  always  having  to 
satisfy  an  authorisation  process.  This  is  easily 
formalised  by  defining  Gu  =  {uj  |  the  integrity 
concern  between  u  and  uj  is  void).  This 
generalization  does  not  effect  the  definition  of  a 
purgeuble  user-command  pair,  and  the  policy  is 
defined  by  replacing  v  e  U\({u}uA„)  in  Policy  2  with  v 
cU\({u}uAuUGu). 

The  last  generalization  we  want  to  make 
concerns  the  actual  commund  thut  a  user  issues.  In 
particular,  suppose  thut  a  user  has  to  seek 
authorization  from  two  different  sources  depending 
upon  the  command  that  he  performs.  The 
combination  of  the  earlier  examples  illustrates  this 
notion.  That  is,  suppose  Paul  wants  to  purchase  a 
Cray  computer.  The  procurement  process  involves 
someone  with  the  capability  to  authorize  the  use  of 
corporate  funds  whereas  the  publishing  process  is 
independent  of  money  matters.  This  suggests  that  a 
user  u  has  an  authorization  tree  for  every  different 
command  that  he  can  issue.  Adding  this  concept 
leaves  us  with  the  final  definition  and  policy 
statement: 

Purgeablo  Def :  A  user  command  pair  (Ui.cj)  e  w  is 
purgeable  with  respect  to  u  iff  u  =  Uj  and  there  is  not 
a  subsequence  of  user-command  pairs  beginning  at 
(ui.cj)  which  define  the  authorization  tree  for  u 
issuing  command  cp 

Integrity  Policy  :  A  system  (finite  state  machine) 
preserves  integrity  provided  that  for  every  ueU  and 
v  r.  U\({u}U  A(UiC)UGu)  we  hove 


u  using  command  e  does  not  interfere  with  v  modulo 
Purge,, 

written 

u,c  :|  v  mod  Purge,, 

III 

out([[w]J,v,r)  =  out([[Purgeu(w)]],v,r) 
for  all  w  c  (UxC)*. 

Remarks: 

Clearly,  we  ought  to  consider  the  question:  are 
all  the  concerns  of  data  integrity  emcompassed  in 
our  policy  definition?  The  answer  is  probably  no. 
For  instance  in  [C  +  WJ  Clark  and  Wilson  state  nine 
rules  which  must  be  satisfied  to  provide  data 
integrity.  Some  of  the  rules  require  procedures 
which  certify  state  transitions  and  data  items;  others 
require  procedures  to  identify  und  authenticate 
every  user  attempting  to  execute  a  transition.  These 
rules,  certainly  germane,  are  not  covered  by  our 
model. 

Our  definition  has  the  advantage  of 
formalizing,  in  our  opinion,  the  notion  of  separation 
of  duty,  a  concept  of  considerable  current  interest 
and  concern  as  pointed  out  forcefully  in  [C+WJ.  To 
use  the  theory  of  non-interference  seems  to  be  a  very 
natural  mathematical  environment  in  which  to  try 
to  express  the  notion  precisely.  There  is  the 
additional  advantage  that  the  theory  has  been 
elegantly  developed  by  Coguen  and  Meseguer, 
Haigh  and  Young,  and  Johnson  and  Thayer. 

Moreover,  we  have  described  a  different  type  of 
non-interference  assertion.  That  is,  a  non¬ 
interference  assertion  that  does  not  purge  like  that 
of  Goguen  and  Meseguer,  nor  does  it  act  like  a 
conditional  non-interference  assertion.  The  reason 
for  this  lies  in  the  definition  of  the  function  Purge,,, 
As  stated  before,  Purge,,  removes  any  occurrence  of 
an  unauthorized  command  issued  by  u,  whereas  the 
Goguen  and  Meseguer  non-inteference  purge 
function  removes  all  occurrences  of  a  eommand(in  a 
certain  set)  issued  by  u  and  the  conditional  non¬ 
interference  purge  function  purges  only  after  a 
specific  occurrence,  thus  allowing  previous 
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unauthorized  events  to  be  effective.  Hence  we  see 
that  the  "power  of  a  non-interference  policy”  fi . e. 
how  much  interference  is  allowed)  is  contingent 
upon  the  definition  of  the  purge  function. 

For  the  moment,  suppose  that  our  purge 
function  actually  behaves  like  a  conditional  non¬ 
interference  assertion.  (Recall  that  the  necessary 
assumption  for  this  example  is  that  any  command 
issued  by  a„  authorizes  all  previous  user-command 
pairs  (u,c)  in  the  sequence  w).  With  this  extra 
hypothesis,  the  integrity  policy  is  directly  related  to 
the  multi-domain  poliey(ML)S)  for  SAT  which  is 
described  in  [II  +  Yj.  The  non-interference 
assertions  in  both  policies  look  fur  an  occurrence  of  a 
"channel",  a  path  from  the  domain  of  user  u  to 
domain  d  in  the  MDS  policy  and  an  "authorization 
tree”  for  user  u  issuing  command  c  for  our  integrity 
policy.  It  is  interesting  that  these  assertions  not  only 
act  the  same  way  on  commands  but  are  considered  to 
comprise  the  mandatory  part  of  the  overall  security 
policy. 

Conclusion 

In  this  paper  we  have  developed  a 
formalization  of  the  concept  of  data  integrity,  the 
basis  of  which  is  separation  of  duty.  Specifically  we 
formalized  the  intuitive  notion  of  an  "authorization 
process"  by  defining  a  purgenble  user-command  pair. 
From  this  definition  we  created  a  purge  function 
which  in  turn  results  in  a  policy  for  integrity.  The 
use  of  non-interference  theory  as  a  mathematical 
environment  in  which  to  describe  the  policy,  not  only 
allows  us  the  capability  to  enhance  our  defintion 
with  aspects  of  integrity  which  may  appear  in  the 
future  as  our  understanding  of  the  concept  deepens, 
but  also  exhibits  a  relationship  between  integrity 
policies  and  multi-level  security  policies  already 
developed  in  non-interFerence  assertions. 
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ABSTRACT 

This  paper  describes  a  model  for  ADP  Risk  Analysis  (RA) 
that  was  developed  in  response  to  the  special  requirements  of 
the  military  data  processing  environment  typified  by  the  De¬ 
fense  Communications  Agency's  (DCA)  Joint  Data  Systems 
Support  Center  (JDSSC)  in  the  Pentagon.  The  reasons  why 
more  traditional  RA  models  and  methodologies  have  failed  in 
this  environment  are  identified.  The  special  challenges  faced 
by  risk  analysts  in  the  military  classified  ADP  environment 
are  described.  This  paper  considers  the  needs  of  security  man¬ 
agement  officials  for  RA  results  in  both  a  single-site  single¬ 
system  environment  and  the  more  typical  multiple-systems 
multiple-sites  environments  faced  by  JDSSC  and  other  mili¬ 
tary  commands.  Finally,  a  methodology  for  RA  is  presented 
that  responds  to  these  needs  through  the  use  of  multiple 
metrics,  a  standardized  threat  nomenclature,  and  standardized 
reporting. 

INTRODUCTION 

During  1987,  work  sponsored  by  the  DCA  JDSSC  ADP  Secu¬ 
rity  Office  (C703)  resulted  in  the  development  of  a  RA  meth¬ 
odology  for  use  by  JDSSC  ADP  Security  officials  during  RAs 
at  World  Wide  Military  Command  and  Control  System 
(WWMCCS)  sites  and  other  installations  operated  and  man¬ 
aged  by  JDSSC.  The  JDSSC  RA  Guide  (RAG)  incorporates  a 
model  and  a  methodology  for  RA  that  is  appropriate  to 
JDSSC’s  needs  but  somewhat  different  from  other  RA  models 
being  used  in  similar  environments.  While  certainly  not  state- 
of-the-art  given  the  science  of  RA,  the  JDSSC  RAG  was  de¬ 
signed  to  provide  practical  guidance  in  die  performance  of  an 
ADP  RA,  not  to  define  new  methods  for  analyzing  diffuse 
risks. 

Unlike  many  other  RA  methodology  results,  the  JDSSC  RAG 
RA  results  are  combinable:  RA  efforts  from  distributed  sites 
can  be  summarized  over  a  large  number  of  installations.  This 
capability  can  be  used  to  identify  the  types  of  "network  secu¬ 
rity  postures"  JDSSC  requires.  Also,  the  JDSSC  RAG  RA  re¬ 
sults  are  abstractable,  producing  the  level  of  RA  reporting 
necessary  for  both  low-level  specific  countermeasures  and 
high-level  JDSSC  policy  decisions  and  budget  planning. 

While  results  from  the  application  of  the  JDSSC  RAG  are  still 
tentative,  they  show  great  promise  for  the  future.  Current  evo¬ 
lutionary  plans  for  the  JDSSC  RAG  include  expansions  in  the 
guidance  provided  for  Network  RAs,  automation  of  the  mode! 
and  the  methodology,  and  the  establishment  of  mechanisms 
for  effective  Risk  Management  in  a  military  ADP  environ¬ 
ment. 

BACKGROUND 

Before  beginning  any  discussion  of  the  JDSSC  RAG,  it  is  ap¬ 
propriate  to  begin  with  a  rapid  review  of  why  ADP  RAs  are 
performed,  what  is  expected  of  them,  and  why  current  meth¬ 
ods  just  don't  seem  to  work. 


RA  is  a  Well  Developed  Science 

What  may  still  distinctly  surprise  many  involved  in  the  busi¬ 
ness  of  ADP  RA  is  that  RA,  in  its  purest  sense,  is  a  well 
developed,  sophisticated,  and  evolving  science.  However,  the 
business  of  ADP  RA  is  not  well  developed,  sophisticated,  or 
evolving.  On  the  contrary.  Little  new  or  innovative  work  in 
ADP  RA  is  occurring  at  all. 

The  science  and  the  art  of  RA  have  been  applied  to  other 
fields  over  a  significant  period  of  time.  RAs  by  professional 
risk  analysts  against  a  wide  variety  of  complex  systems  have 
been  conducted.  Notable  among  non-ADP  RA  efforts  was  a 
study  conducted  to  determine  the  safety  of  commercial  nu¬ 
clear  power  stations  [1].  The  RA  contained  detailed  examina¬ 
tions  of  the  safety  mechanisms  incorporated  into  commercial 
reactor  systems,  and  it  plotted  the  failure  rates  of  individual 
components  (as  well  as  related  and  dependent  components  in 
combination)  against  the  potentials  for  measurable  leakages 
of  radiation.  A  highly  quantified  study,  it  has  been  widely 
cited  as  an  illustration  of  what  the  process  of  RA  should  be. 

As  RA  has  evolved,  organizations  such  as  the  Risk  Analysis 
Society  have  greatly  extended  the  types  of  problems  which 
can  be  considered  through  quantitative  methods.  Non- 
bayesian  techniques  for  evaluating  risk  have  been  developed 
and  applied  to  a  wide  variety  of  problems  not  amenable  to 
deterministic  evaluation. 

Origins  of  ADP  RA  -  Basic  Mandates 
The  business  of  ADP  RA  can  be  said  to  have  begun  with  the 
publication  of  Transmittal  Memorandum  Number  1  to  the  Of¬ 
fice  of  Management  and  Budget's  Circular  A-71  [2].  OMB 
A-71/TM#1  required  that  ail  executive  branch  departments 
and  agencies  develop  and  implement  computer  security  pro¬ 
grams.  Within  this  original  guidance,  RAs  were  explicitly 
called  for  at  all  computer  installations  operated  by  or  for  the 
federal  government  "to  provide  a  measure  of  the  relative  vul¬ 
nerabilities  at  the  installation  so  that  security  resources  can 
effectively  be  distributed  to  minimize  the  potential  loss."  RAs 
were  required  for  ail  installations  each  time  a  significant 
change  occurred,  or  at  least  once  every  five  years. 

Both  before  and  after  the  publication  of  OMB  Circular 
A-71/TM01,  the  Department  of  Commerce  published  a  series 
cf  standards  and  guidelines  to  aid  federal  agencies  in  the  per¬ 
formance  of  RAs  [3]  [4]  [5],  The  requirements  and  specific 
methodologies  for  RA  have  also  been  incorporated  into  a 
number  of  Department  of  Defense  (DoD)  regulations  includ¬ 
ing  [6],  [7],  and  [8], 

The  original  guidance  from  the  OMB  has  recently  been  re¬ 
placed  as  OMB  A-130  [9],  The  requirements  in  the  current 
OMB  Circular  are  only  slightly  more  explicit  than  those  origi¬ 
nally  contained  in  [2]  -  "The  objective  of  a  Risk  Analysis  is  to 
provide  a  measure  of  the  relative  vulnerabilities  and  threats  to 
an  installation  so  that  security  resources  can  be  effectively 
distributed  to  minimize  potential  loss,"  However,  the  current 
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circular  does  allow  for  a  variance  in  the  formalism  of  the 
analysis  based  on  the  size  of  the  installation  -  “Risk  Analyses 
may  vary  from  an  informal  review  of  a  microcomputer  instal¬ 
lation  to  a  formal,  fully  quantified  risk  analysis  of  a  large 
scale  computer  system." 

This  softening  in  the  requirement  is  perhaps  in  response  to 
the  realities  of  ADP  RA  state-of-the-practice.  Many  ADP 
managers  perceive  ADP  KAs  costly,  time-consuming,  and  of 
questionable  value  to  management  planning.  The  next  section 
of  this  paper  reviews  the  problems  with  ADP  RA  in  more 
detail. 

REQUIREMENTS  ANALYSIS 

The  development  of  the  JDSSC  RAG  generally  followed  the 
stages  of  the  standard  product  lifecycle,  beginning  with  an  an 
analysis  of  the  requirements  that  must  be  satisfied  by  the 
JDSSC  ADP  RA  methodology.  Following  this  analysis,  a  num¬ 
ber  of  ideas  were  prototyped  for  evaluation  through  their  ap¬ 
plication  to  a  live  analysis  effort. 

The  primary  management  benefit  of  an  ADP  RA  is  that  the 
quantified  evaluation  of  risk  (i.e.,  relative  criticality  based  on 
some  common  metric  -  the  basis  of  all  RA  efforts)  is  highly 
useful  as  a  yardstick  of  relative  need.  During  the  process, 
management  also  gains  an  insight  into  problems  faced  at  sev¬ 
eral  system  levels,  many  of  which  are  normally  hidden  be¬ 
cause  of  overall  system  complexity.  Decisions  to  act  based  on 
RA  results  assure  the  best  use  of  available  funding,  where 
best  is  defined  by  the  metric  employed.  If  the  metric  em¬ 
ployed  is  dollars,  then  RA  points  towards  the  actions  that 
make  the  best  economic  sense.  As  described  earlier,  however, 
dollars  are  not  the  only  possible  metric,  and  other  methods  for 
quantifying  loss  can  be  used  in  situations  where  fiscal  eco¬ 
nomies  arc  inappropriate. 

A  secondary  benefit  from  ADP  RA  is  the  opportunity  to  reac- 
quaint  staff  personnel  with  the  importance  of  the  data  proc¬ 
essing  resource  to  overall  mission  objectives.  Through  the 
identification  of  real  and  potential  losses,  the  extent  of  the 
reliance  on  an  ADP  resource  is  rediscovered.  Most,  if  not  all, 
user  mission  objectives  are  directly  dependent  upon  the  suc¬ 
cess  of  the  ADP  organization.  In  the  absence  of  the  ADP  re¬ 
source,  no  alternative  means  for  user  mission  satisfaction  are 
available.  The  true  extent  of  DoD  reliance  on  its  ADP  re¬ 
sources  is  only  poorly  understood  by  most  data  processing 
professionals  involved  in  supporting  these  resources. 

Another  secondary  benefit  from  the  process  of  RA  is  the  iden¬ 
tification  of  important  dependencies.  Seemingly  unimportant 
resources  and  functions  cun  play  paramount  roles  in  overall 
system  reliability.  Within  an  ADP  environment,  the  reliability 
of  the  entire  ADP  resource  can  be  focused  on  individual 
pieces  of  equipment  and  specific  personnel.  Even  minor  fail¬ 
ures  can  have  major  impacts  on  an  entire  installation.  Ramifi¬ 
cations  of  minor  problems  in  the  ADP  environment  can  mean 
disasters  for  user  organizations. 

Problems  with  Existing  ADP  RA  Methods  and  Models 
Many  models,  methodologies,  and  tools  supporting  (some  pur¬ 
porting  to  'automate')  ADP  RA  have  been  produced  and  em¬ 
ployed  by  different  federal  department  and  agencies  (7j  [8] 
!  1 0 j  j  1 1 1  [  1 2 j .  These  models  of  ADP  RA,  and  the  particular 
methodologies  supporting  them,  vary  from  agency  to  agency, 
from  regulation  to  regulation,  arid  from  standard  to  standard. 
Seemingly,  the  only  thing  that  all  existing  ADP  RA  method¬ 


ologies,  tools,  and  models  have  in  common  is  their  diversity. 
Nearly  every  existing  methodology,  tool,  and  model  has  its 
own  positive  and  negative  points  [13).  Few  arc  compatible 
with  any  other  approach.  Nearly  all  are  based  on  a  purely 
financial  analysis  of  loss  and  cost-effectiveness  of  counter¬ 
measures. 

Considerable  resources  have  been  invested  over  the  past  ten 
years  in  the  performance  of  ADP  RAs.  A  cottage  industry  in 
the  performance  of  RAs  has  emerged  to  service  the  ADP  RA 
needs  of  the  federal  marketplace.  Unfortunately,  the  diversity 
and  the  impropriety  of  the  methods  for  ADP  RA  being  em¬ 
ployed  have  raised  serious  doubts  about  the  utility  of  the  proc¬ 
ess  to  ADP  management. 

ADP  RA  results  have  been  widely  criticized  for  (I)  their  sizes 
-  ADP  RAs  can  produce  volumes  of  detailed  data  of  question¬ 
able  accuracy  or  utility,  (2)  their  diversity  -  managers  are 
faced  with  a  wide  variety  of  RA  results  from  different  efforts, 
and  (3)  their  nature  -  the  types  of  issues  considered  by  differ¬ 
ent  RA  methodologies  and  models  are  different,  and  ADP  RA 
is  highly  dependent  upon  the  personnel  performing  the  analy¬ 
sis. 

Within  the  military  environment,  experiences  in  the  perform¬ 
ance  of  ADP  RAs  have  been  much  the  same  as  for  non-DoD 
agencies.  Unfortunately  for  the  DoD,  where  the  greatest  reli¬ 
ance  on  ADP  exists,  and  where  the  most  significant  risks  are 
faced,  none  of  the  methodologies  for  RA  is  at  all  appropriate. 
Without  exception,  these  methodologies,  models,  and  tools 
fail  to  properly  appreciate  the  priorities  of  the  military  envi¬ 
ronment.  These  priorities  include  elements  that  are  crucial 
considerations  in  ADP  RA: 

1.  Unlike  most  other  federal  agencies,  the  DoD  ADP  systems 
process  classified  information  that  must  be  protected  to 
the  maximum  extent  possible.  Military  command  and  con¬ 
trol  systems  process  information  vital  to  the  national  de¬ 
fense. 

2.  System  failures  in  the  military  environment  have  implica¬ 
tions  for  national  security,  not  just  finance.  The  eventual 
users  of  military  systems  include  all  military  commands 
and  elements.  Failures  of  different  military  systems  have 
differing  levels  of  implications. 

3.  Policy  decisions  and  budget  allocations  in  the  DoD  are 
made  centrally.  Current  ADP  RAs  are  highly  system-  and 
environment-specific  processes.  Thus,  policy  decisions 
must  be  based  on  very  detailed  RA  results. 

4.  An  ADP  RA  requires  so  much  time  and  associated  re¬ 
sources  that  the  known  risk  posture  within  a  single  author¬ 
ity  or  command  (such  as  JDSSC)  cannot  be  kept  current. 
Practical  means  are  unavailable  for  keeping  ADP  RA  re¬ 
sults  up  to  dote  in  a  rapidly  changing  environment. 

5.  A  significant  level  of  expertise  is  required  for  the  perform¬ 
ance  of  a  quality  ADP  RA.  It  is  difficult  to  provide  suffi¬ 
cient  guidance  in  the  performance  of  ADP  RAs  that  inex¬ 
perienced  personnel  can  produce  useful  results. 

Currently  available  tools  JDSSC  evaluated  before  the  JDSSC 
RAG  was  developed  were  found  to  be  universally  difficult  to 
use  or  tailor  to  specific  environments,  lacking  in  mechanisms 
for  maintaining  RA  results,  and  unable  to  produce  both  de¬ 
tailed  and  abstracted  results.  The  Los  Alamos  Vulnerability 
Analysis  (LAVA)  tool  received  from  the  National  Computer 
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■Security  Center  (NCSC)  was  evaluated  in  depth.  The  evalu¬ 
ation  concluded  that: 

1.  l.AVA  can  be  quite  cumbersome  to  use.  If  questions 
within  its  automated  questionnaire  are  answered  incor¬ 
rectly:  no  mechanisms  exist  for  their  specific  modification. 

2.  While  LAVA’S  extensive  automated  questionnaire  quite 
well  addresses  the  areas  within  its  scope,  no  mechanism  is 
provided  to  address  issues  outside  of  the  defined  areas. 
Non-addrcsscd  areas  included  TEMPEST,  office  automa¬ 
tion,  personal  computers,  Operations  Security  (OPSEC), 
and  word  processing. 

3.  The  report  LAVA  produces  is  difficult  to  read,  and  con¬ 
veys  less  insight  to  actual  security  conditions  than  does  an 
annotated  copy  of  the  input  questionnaire  upon  which  the 
report  is  based.  Vulnerability  ratings  are  presented  with  no 
description  of  their  basis. 

4.  LAVA  is  based  on  assumptions  about  the  types  of  threats 
to  which  the  data  processing  resource  is  exposed.  For  this 
to  be  reasonable,  other  assumptions  must  be  made  about 
the  scope  of  the  analysis  LAVA  is  able  to  support. 

JDSSC's  analysis  of  LAVA,  the  National  Aeronautics  and 
Space  Administration's  (NASA)  Self  Analysis  Guide 
(SAGUD),  and  latnee  Hoffman’s  kISKCALC,  among  others, 
have  resulted  in  the  following  conclusions  about  available 
ADP  RA  methodologies  and  tools: 

1.  None  of  the  examined  methodologies  or  tools  provides  suf¬ 
ficient  comparison  of  RA  results  across  different  systems 
or  installations. 

2.  None  of  the  examined  methodologies  or  tools  adequately 
addresses  the  issues  of  mission  satisfaction  or  information 
compromise. 

3.  The  tools  examined  are  not  sufficiently  flexible  or  expand¬ 
able  to  be  useful  to  JDSSC  because  of  the  dynamic  nature 
of  the  JDSSC  ADP  environment. 

4.  None  of  the  examined  methodologies  or  tools  allows  risk 
analysis  results  to  be  collected  and  accumulated  across  in¬ 
stallations  for  strategic  planning  and  abstract  analysis. 

While  the  failings  of  particular  tools  and  methodologies  differ, 
no  existing  tool  or  methodology  seems  to  solve  some  prob¬ 
lems: 

1.  The  value  of  classified  information  is  difficult  to  quantify. 
No  reliable  method  exists  for  determining  the  value  of 
classified  information  in  the  general  case.  No  formula  is 
possible  that  factors  in  the  real  value  of  classified  infor¬ 
mation  to  a  potential  adversary. 

2.  The  values  of  assets  are  not  identical  in  all  instances.  The 
value  of  classified  information  when  compromised,  for  ex¬ 
ample,  is  much  greater  than  the  value  of  classified  infor¬ 
mation  unintentionally  destroyed  (e.g. ,  in  a  fire).  Valu¬ 
ation  must  be  as  a  function  of  the  threuts  an  asset  is 
exposed  to,  a  point  missed  by  most,  if  not  all,  established 
methodologies. 

3.  Losses  experienced  due  to  ’mission  dissatisfaction’  can  in¬ 
clude  a  decrease  in  U.S.  defense  readiness.  Threats  which 
might  affect  mission  satisfaction  are  difficult  to  quantify 
realistically.  As  a  result,  RA  findings  that  imply  effects 


against  mission  satisfaction  are  typically  under-  or  over¬ 
emphasised  by  the  losses  attributed  to  them. 

4.  None  of  the  established  methodologies  allow  for  sufficient 
comparison  or  abstraction  of  ADP  RA  results.  ADP  RA 
results  must  be  comparable  across  systems  and  installa¬ 
tions  and  must  be  easily,  intuitively,  and  quickly  under¬ 
stood  by  laymen. 

5.  The  maintenance  of  ADP  RA  results  is  not  well  supported 
in  a  very  dynamic  and  networked  environment.  No  provi¬ 
sions  exist  for  rapid  calculations  based  on  ’what  if’  scenar¬ 
ios  against  risk  analysis  results,  or  for  the  dynamics  of  an 
environment  with  rapidly  changing  threats  and  assets. 

6.  Risk  Management  (the  continuing  identification  of  risks, 
and  the  corrective  actions  taken  in  response  to  identified 
risks)  is  not  sufficiently  emphasized  by  existing  tools  or 
methodologies.  Some  tools  include  no  provisions  for  Risk 
Management  whatsoever. 

7.  Even  within  a  given  methodology,  RA  results  tend  to  vary, 
and  even  strong  methodologies  can  result  in  ADP  RA  re¬ 
sults  that  are  inconsistent  with  prior  studies  in  the  same 
installation.  Strong  guidelines  for  the  analysis  techniques, 
scope  and  categories  of  investigation  are  needed  to  ensure 
consistent  ADP  RA  results. 

To  a  large  extent,  the  methods  employed  cause  the  problems 
with  ADP  RAs.  1 14]  stated  that  “The  majority  of  computer 
security  risk  analyses  have  used  annual  loss  expectancies 
(ALEs),  a  method  well-suited  to  and  used  by  insurance  com¬ 
panies."  Most  methodologies  examined  compute  the  ALEs 
in  terms  of  dollars.  However,  dollars  are  an  inappropriate 
measure  of  many  risks  faced  in  the  military  environment. 
Losses  of  classified  information,  or  of  the  implications  inher¬ 
ent  in  potential  failures  of  critical  defense  ADP  systems,  just 
cannot  be  stated  in  terms  of  “dollars  lost"  per  instance  or  per 
year. 

[14]  also  concludes  that  the  science  has  been  hampered  by  the 
lack  of  available,  appropriate  metrics  to  apply  to  intangible 
losses.  1 14]  further  identifies  means  to  analyze  diffuse  and 
undefined  risks.  Both  [  1 4 1  and  ]  1 5 1  discuss  the  need  to  better 
apply  the  true  science  cf  RA  to  the  problem  of  ADP  RA 
through  non-bayseian  techniques.  However,  in  the  analyses 
which  led  to  the  production  or  the  JDSSC  RAG,  the  problems 
with  the  techniques  used  to  compute  risk  (ALEs)  were  seen  as 
less  indicative  of  why  current  models  have  failed  to  be  useful 
than  the  problems  obvious  with  the  techniques  used  to  com¬ 
pute  specific  loss.  It  was  felt  that  dollars  lost  were  an  ex¬ 
tremely  inappropriate  way  to  express  the  potentials  involved 
in  classified  information  compromise  and  in  denial  of  service 
for  crucial  military  ADP  resources. 

Although  highly  quantified  computer  security  RAs  have 
tended  to  become  quickly  overbearing,  unquantified  analyses 
face  other  risks.  Unless  supported  by  some  form  of  quantifi¬ 
cation,  findings  of  vulnerability  and  recommendations  for 
countermeasures  and  safeguards  are  reduced  to  opinion  and 
conjecture. 

It  is  in  the  quantification  of  risk  that  RA  derives  its  benefits. 
Qualitative  assessments  of  security  (physical  security,  techni¬ 
cal  security  within  systems,  and  administrative  controls,  etc.) 
by  experienced  analysts  usually  identify  many  weaknesses  for 
which  remedial  actions  can  be  recommended  and  reasonably 
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supported.  Unfortunately,  no  budget  is  sufficient  to  allow  im¬ 
plementation  of  every  safeguard  that  looks  attractive  or  which 
seems  necessary.  In  the  military  environment,  as  elsewhere, 
many  reviews  have  been  conducted  based  on  this  “best  guess” 
approach,  resulting  in  recommendations  which  may  not  have 
been  the  best  application  of  available  funding. 

(16]  warns  against  the  qualitative  approach  to  computer  secu¬ 
rity:  “Security  Measures  are  cost-effective  only  when  the 
losses  that  are  displaced  are  significantly  greater  than  the 
[cost  of  the]  security  measures."  Although  individual  prob¬ 
lems  are  easy  to  evaluate  on  their  own  merits,  the  “common 
sense"  approach  quickly  breaks  down  when  applied  to  many 
concurrent  problems.  The  problems  facing  management  may 
also  be  extremely  complex  and  require  a  deep  understanding 
of  the  specific  situation  to  appreciate  the  need  for  any  reme¬ 
dial  action.  Only  by  somehow  quantifying  risk  can  different 
problems  be  realistically  compared  and  decisions  made  about 
safeguard  implementations  really  supported.  (16j  recom¬ 
mends  that  analysts  “do  a  comprehensive  job  of  problem  defi¬ 
nition  and  gross  quantification  before  attempting  the  imple¬ 
mentation  of  computer  security  measures.” 

While  several  ADP  RA  methodologies  are  in  use,  most  were 
intended  for  application  to  non-defense  systems,  where  eco¬ 
nomics  plays  the  major  role  in  management  decision  making. 
JDSSC's  special  challenges  are  not  satisfied  through  any 
methodology  or  tool  demonstrated  to  date,  in  part  because 
many  of  the  situations  it  faces  do  not  lend  themselves  to  a 
purely  financial  analysis.  Safeguards  over  classified  informa¬ 
tion.  for  example,  are  difficult  to  justify  by  dollars  saved.  De¬ 
fining  the  JDSSC  RAG  first  required  reviewing  what  the 
JDS.SC  environment  required. 

JDSSC  manages  systems  critical  to  national  security,  distrib¬ 
utee!  across  a  wide  geographic  region,  its  mission  includes 
support  of  (1)  the  National  Military  Command  Center 
(NMCC)  supporting  the  Organization  of  the  Joint  Chiefs  of 
Staff  (OJCS),  the  Office  of  the  Secretary  of  Defense  (OSD), 
and  the  National  Command  Authority  (NCA);  (2)  the  Alter¬ 
nate  Military  Command  Center  (ANMCC);  and  (3)  a  wide 
variety  of  smaller  and  more  specialized  operational,  develop¬ 
mental,  and  research  systems  and  networks  (both  local  and 
wide  area)  supporting  critical  defense  needs.  In  the  near  fu¬ 
ture,  classified  networks,  office  automation,  and  classified 
word  processing  systems  will  probably  become  even  more 
prevalent  than  they  are  today.  Due  to  this  variety  of  support 
areas,  JDSSC’s  most  important  requirement  for  ADP  RA  is 
for  techniques  sufficiently  flexible  for  each  of  these  diverse 
types  of  systems  and  which  allow  identification  of  the  types  of 
risks  each  faces.  In  practical  terms,  and  because  some  of  the 
automation  security  requirements  for  networks  (as  one  exam¬ 
ple)  are  not  fully  defined  today,  the  methodology  must  be  ex¬ 
pandable. 

Some  systems  managed  and  operated  by  JDSSC  are  subject  to 
security  requirements  based  cn  their  processing  modes, 
JDSSC  systems  process  classified  information  at  various  lev¬ 
els,  and  each  level  is  associated  with  increasing  requirements 
for  computer  security.  The  ADP  RA  methodology  required  by 
JDSSC  must  include  provisions  for  these  types  of  considera¬ 
tions. 

Security  management  within  JDSSC  is  centralized.  Any  rec¬ 
ommendations  must  be  based  on  identification  of  the  most 
critical  problems  among  all  JDSSC  systems  so  that  decisions 


can  be  made  about  where  action  (new  or  revised  policies,  etc.) 
is  most  needed.  A  second  important  consideration  for  JDSSC 
is  the  need  for  a  methodology  that  can  allow  security  manage¬ 
ment  officials  to  realistically  compare  problems  across  sys¬ 
tems  and  installations  and  to  make  summary  decisions  at  the 
policy  level  based  on  this  information. 

Personnel  responsible  for  budget  allocations  have  only  a  lim¬ 
ited  understanding  of  the  details  of  each  system  supported  by 
JDSSC.  These  officials  must  be  provided  with  summary  infor¬ 
mation  that  can  be  rapidly  assimilated  without  reviewing  vo¬ 
luminous  reports  or  detailed  calculations.  Techniques  for  ADP 
RA  results  abstraction  are  needed  to  support  high-level  man¬ 
agement  decision  making. 

Prior  ADP  RAs  performed  against  JDSSC  systems  have  identi¬ 
fied  major  risks.  Recommendations  for  the  implementation  of 
countermeasures  were  based  on  the  findings,  and  actions  were 
assigned  to  different  organizations  to  ensure  that  risks  were 
mitigated.  Follow-on  reviews  revealed,  however,  that  in 
many  cases  ADP  RA  recommendations  were  not  acted  upon, 
and  that  risks  identified  during  analyses  were  still  present 
when  the  next  analysis  was  performed.  JDSSC  needed  mecha¬ 
nisms  to  provide  for  proper  Risk  Management.  A  system  was 
needed  to  ensure  that  ADP  RA  results  were  acted  upon  in  a 
timely  manner  and  that  dependent  situations  (where  multiple 
actions  were  needed  to  respond  to  single  risks)  were  success¬ 
fully  tracked. 

In  the  past,  JDSSC  has  attempted  to  perform  RAs  according 
to  defined  methodologies  and  guidelines  published  by  various 
sources.  There  have  been  problems  in  applying  standardized 
techniques  to  JDSSC  systems,  and  the  standardized  tech¬ 
niques  have  not  fully  met  all  JDSSC  requirements  for  ADP 
RA  and  risk  management.  These  problems  fall  into  four  major 
categories: 

J.  Technology.  JDSSC  is  involved  in  state-of-the-art  applica¬ 
tion  of  available  technology  for  secure  networks,  secure 
systems,  office  automation,  and  classified  word  processing 
systems.  Mechanisms  needed  to  evaluate  these  types  of 
systems  are  not  included,  incomplete,  or  not  expandable 
or  modifiable. 

2.  Comparative  Results.  JDSSC  management  must  be  able  to 
compare  results  obtained  from  analyses  at  one  installation 
with  those  obtained  at  other  installations.  Methodologies 
not  designed  to  support  comparisons  between  installations 
are  difficult  to  use  for  this  purpose. 

3.  Results  Abstraction.  The  budget  allocation  process  must 
be  supported  by  information  that  is  brief,  concise,  rapidly 
understandable,  and  that  does  not  require  a  detailed  un¬ 
derstanding  of  the  systems  or  specific  problems  involved. 
In  most  of  the  tools  and  methodologies  used,  the  results 
are  presented  in  lengthy  reports  which  contain  detailed 
computations,  none  of  which  is  suitable  for  JDSSC. 

4.  Risk  Management,  Mechanisms  are  needed  to  ensure  that 
ADP  RA  results  are  acted  upon  in  a  timely  manner  and  to 
track  progress  toward  planned  goals.  No  current  tools  or 
methodologies  sufficiently  provide  for  this  need. 

In  general  terms,  the  concepts  involved  in  ADP  RA  are  rela¬ 
tively  simple.  Problems  are  discovered,  the  assets  involved  are 
valued,  the  frequencies  of  occurrence  are  determined  or  esti¬ 
mated,  the  losses  are  computed,  and  countermeasures  are 


46 


postulated  and  analyzed.  Problems  often  arise,  however,  in 
applying  this  relatively  simple  concept  to  the  JDSSC  environ¬ 
ment.  The  problems  arise  from  unique  aspects  of  these  sys¬ 
tems  and  from  shortcomings  in  a  number  of  popular  method¬ 
ologies  and  tools. 

DESIGN  OF  THE  JDSSC  AI)P  RA  METHODOLOGY 

The  JDSSC  ADP  RA  methodology's  basic  requirements  are 
that  new  approaches  be  developed  to  account  for  the  failings 
of  the  currently  available  methods.  The  JDSSC  RAG  is  de¬ 
signed  around  an  approach  for  quantifying  “risk”  that  docs 
not  depend  upon  dollars  as  the  sole  measure  of  loss. 

ADP  RA  Risk  Model 

Earlier,  we  reflected  on  the  sophist. cated  work  being  done  to 
analyze  diffuse  risks  by  professional  risk  analysts  outside  of 
the  ADP  field.  Others  have  described  now  these  methods 
might  be  more  appropriate  than  the  more  simplistic  model  of 
risk  nearly  all  ADP  RA  models  employ.  The  ADP  RA  objec¬ 
tive  is  not.  however,  the  most  accurate  portrayal  of  the  true 
extent  ol  risks.  Mandates  require  only  the  accurate  ranking  of 
relative  risks  to  the  ADP  resource. 

For  the  purposes  of  an  ADP  RA  (done  quickly,  and  with  only 
a  limited  amount  of  time  to  quantify  results),  the  model  of 
risk  must  ADP  RA  methodologies  employ  may  be  the  most 
appropriate  and  is  certainly  quite  adequate: 

RISK  ALL  =  AIL  x  SI-E 

RISK  ALE  Annual  Loss  Expectancy.  A  measure  of  the 
extent  of  the  danger  from  a  given  threat. 

A I  P.  Annual  Frequency  Estimate.  How  often  a 

given  negauve  event  is  expected  to  occur. 

SI  . I  Single  Loss  Estimate  Some  measure  of  ex¬ 

actly  what  the  results  of  that  negative  event 
will  be  each  time  it  occurs. 

Hie  model  allows  evaluation  and  relative  ranking  of  negative 
events  (threats).  It  is  beyond  the  scope  of  this  paper  to  debate 
the  advantages  of  alternative  models  of  risk.  Suffice  it  to  say 
that  vc  belie e  that  this  model  in  its  most  general  sense  is 
sufficient  to  this  application,  and  that  its  inaccuracies  arc  well 
hid  :lcn  by  the  fallacies  inherent  in  any  attempt  to  quantify 
threat  Ireqeneics  or  the  true  loss  that  will  be  experienced  in 
any  disaster 

ADP  RA  Results  Evaluation 

Numbers  arc  used  in  an  ADP  RA  not  to  absolutely  quantify 
the  exact  risk,  but  rather  to  relatively  rank  risks.  As  a  result, 
and  because  ol  the  inaccuracies  built  into  any  evaluation  of 
risk,  the  process  of  API'  RA  is  at  the  same  time  highly  quali¬ 
tative  tic.,  judgmental'  and  quantitative  (i.c..  based  on  num¬ 
bers).  I :r.dei standing  exactly  what  the  results  of  an  ADP  RA 
cl  fort  mean  land  what  they  do  noil  and  how  these  results  can 
support  risk  mitigation  is  important.  Without  an  appreciation 
ol  the  inaccuracies  of  the  process,  misconceptions  are  prob¬ 
able 

A  major  misconception  can  occur  v  uen  risk  is  expressed  as  a 
ligure,  an  ALE.  l  or  example,  an  ALE  of  S27.000.00  due  to 
tires  in  the  computer  room  must  be  taken  with  a  truckload  of 
salt.  No  installation  (still  standing)  loses  this  much  every  year. 
Even  a  liberal  interpretation  (the  figure  divided  by  the  likeli¬ 
hood  ol  a  fire  yielding  some  figure  for  the  potential  damage  a 
fire  is  likely  to  cau-el  is  unrealistic.  No  study  can  exactly  pre¬ 


dict  losses  or  the  cost  of  recovering  them.  Postulations  of  po¬ 
tential  losses  are  hypothetical  at  best.  Real  disasters  are 
messy,  vvorse-than-worst-case,  and  wholly  unpredictable.  An 
installation  with  an  excellent  fire  safety  program  can  be  de¬ 
stroyed  by  fire  immediately  after  receiving  a  clean  bill  of 
health  from  the  local  fire  marshal. 

What  then  do  ALEs  represent,  if  the  real  costs  associated  with 
disasters  cannot  be  reliably  established  in  advance?  They  rep¬ 
resent  the  magnitude  of  the  potential  or  risk.  Problems  or 
threats  with  high  ALEs  are  more  important  than  those  with 
low  ALEs.  Only  in  this  relative  and  qualitative  ranking  do  the 
numbers  employed  in  the  process  have  their  place. 

Management  has  a  limited  budget  and  a  limited  opportunity 
for  positive  change.  ADP  RA  techniques  indicate  where  im¬ 
provements  are  most  needed  and  where  resources  can  best  be 
applied.  That  is  all.  In  the  situation  described  above,  manage¬ 
ment  would  be  wrong  to  assume  that,  by  setting  aside  the 
ALE  for  fire  every  year,  that  they  would  be  covered  in  the 
event  of  a  fire  disaster.  They  would  also  be  wrong  to  assume 
that  any  safeguard  costing  less  than  27K  annually  is  cost- 
effective.  This  risk  must  be  compared  with  others,  and  what  is 
possible  to  mitigate  those  risks  which  appear  most  threatening 
must  be  postulated.  The  relative  cost-effectiveness  of  counter¬ 
measures  must  be  assessed  against  the  most  relatively  serious 
risks.  In  many  cases,  doing  anything  to  reduce  either  the  like¬ 
lihood  or  the  potential  impact  of  identified  risks  may  not  be 
cost-effective.  Their  identification  is  still  important. 

The  value  of  the  process  lies  not  in  the  exactness  of  the  fig¬ 
ures  employed  but  in  their  magnitudes,  reasonableness,  and  in 
the  relative  ranking  of  problems  based  on  their  consistent  ap¬ 
plication  across  a  range  of  situations.  There  is  a  great  desire 
for  techniques  and  "truly  scientific"  methods  to  overcome  the 
vagaries  of  the  ADP  RA  process.  These  desires  spring  from 
fears  that  the  actual  numbers  employed  in  ADP  RAs  are  unre¬ 
alistic.  1'he  fears  are  justified  Real  numbers  could  never  be 
produced  in  advance.  Even  close  estimations  are  difficult  at 
best.  Experiences  with  well  known  threats  (Courtney's  five 
major  sins,  etc.)  tend  to  support  the  contention  that,  through 
quantification,  a  reasonable  qualitative  ranking  can  be 
achieved. 

Increases  in  the  accuracy  of  the  values  for  assets  (and  the 
other  assumptions  such  as  threat  frequencies)  do  not  increase 
the  accuracy  of  the  process.  Quantified  ADP  RAs  are  per¬ 
formed  to  avoid  the  only  alternative,  a  best-guess  qualitative 
ranking  of  problems.  Guessing  (i.c.,  estimating  asset  values, 
threat  frequencies,  and  relative  degrees  of  exposure)  is  still 
required,  but  is  performed  in  limited  ways.  Upper  and  lower 
bounds  for  the  guess  am  provided  as.  for  example,  statistics 
for  threat  frequencies  and  equipment  purchase  costs.  The 
methods  yield  generally  supportable  rankings  for  problems 
that  can  be  intuitively  ranked,  and  they  increase  the  confi¬ 
dence  in  the  rankings  of  less  easily  understand  problems. 

Risk  Analysis  Metrics 

In  nearly  every  appli  ation  of  the  traditional  RA  model  to 
ADP  RA.  the  SLE  and  the  RISK  ALE  are  demonstrated  as 
dollars.  During  the  analysis  preceding  the  development  of  the 
JDSSC  RAG.  however,  we  wondered  if  other  measures  of 
“risk"  might  also  be  useful  when  dollars  (as  u  measure  of 
loss)  were  inappropriate  Those  areas  where  financial  analy¬ 
ses  are  most  inappropriate  are  information  compromise  and 
system  downtime.  Alternative  metrics  were  devised  and  ap¬ 
plied  to  a  live  analysis  effort  as  an  evaluation  of  their  utility. 
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Infonnaiion  Compromise:  A  metric  for  information  com¬ 
promise  was  based  on  a  qualitative  review  of  elements  of  the 
compromise  threat.  We  decomposed  the  threat  as  the  inherent 
risk  associated  with  the  classification  level  of  information 
(Top  Secret  data  is  inherently  more  valuable  than  Confidential 
information),  the  extent  of  the  compromise  '.need  to  know  vio¬ 
lations  are  less  severe  than  a  leukage  from  Top  Secret  to  Un¬ 
classified),  the  extent  of  the  loss  (a  little  data  is  less  valuable 
than  a  great  volume  of  data  if  the  other  factors  remain  the 
same),  and  the  utility  of  the  compromised  information  (auto¬ 
mated  media  at  high  density  or  high  speed)  is  more  useful 
than  paper  output. 

Tor  information  compromise,  the  SLE  is  computed  as  a  for¬ 
mula: 

SLE  =  C  x  E  x  A  x  L 

C  A  Multiplier  based  on  the  highest  classification  of 
data  which  could  be  exposed.  Note  1. 

E  The  percentage  of  the  total  volume  of  data  (contained 
within  the  system  being  examined)  that  is  exposed  to 
the  threat.  Note  2. 

A  A  multiplier  based  upon  the  avenue  through  which 
the  information  is  exposed.  Note  3. 

1  The  number  of  classification  levels  over  which  infor¬ 
mation  exposure  occurs.  Note  4. 

Note  I .  Classification  multipliers  were  established  on  an  or¬ 
der  of  magnitude  scale  to  allow  the  formula  to  be  biased  ap¬ 
proximately  equally  between  a  small  volume  of  highly  classi¬ 
fied  data  and  a  large  volume  of  less  highly  classified  data  due 
to  the  Inferences  possible  through  volume  and  the  probability 
of  classification  through  aggregation. 

Note  2.  Exposure,  a  factor  applied  to  all  formulas  in  the 
JDSSC  RAG,  is  used  to  apply  granularity  within  undefined 
assets,  such  as  system  information  volumes. 

Note  3,  The  Avenue  multiplier  was  originally  devised  as  a 
measure  of  the  bandwidth  of  compromise  (volume  over 
speed).  In  practice,  the  data  required  to  accurately  compute 
bandwidth  is  generally  unavailable  or  difficult  to  compute, 
and  a  rougher  measure  (the  avenue  multiplier  is  described 
below)  was  employed. 

Note  4.  The  number  of  levels  is  a  multiplier  to  describe  the 
increasing  loss  potential  as  information  is  compromised 
across  need  to  know  (level  1)  and  classification  level  (Confi¬ 
dential  to  Unclassified  is  Level  2,  Secret  to  Confidential  is 
Level  3.  etc.)  boundaries. 

Because  ADP  systems  are  vulnerable  to  compromise  of  infor¬ 
mation  through  various  types  of  mechanisms,  the  metric  in¬ 
cludes  an  Avenue  Multiplier  to  allow-  the  speed  of  leakage  to 
be  considered: 

10  -  Information  exposed  over  high-speed  communications 
lines  to  remote  installations. 

9  -  Information  exposed  to  local  automated  processes  on 
high  speed  media 

8  -  information  exposed  to  local  automated  processes  on 
lower  speed  media. 

7  -  Information  exposed  over  low-speed  communications 
lines  to  remote  installations. 


6  -  Information  exposed  to  high  speed  terminal  devices 
with  local  storage  capability. 

5  -  Information  exposed  to  high  speed  terminal  devices 
without  local  storage  capability. 

4  -  Information  exposed  to  low  speed  display  terminals. 

3  -  Information  exposed  to  high  speed  hard  copy  termi¬ 
nals. 

2  -  Information  exposed  to  low  speed  hard  copy  termi¬ 
nals. 

1  -  Information  exposed  on  paper  only  -  not  automated 
media. 

The  scale  allows  high  risk  exposures  in  an  automated  environ¬ 
ment  (i.e.,  high  speed  data  leakage  in  a  digital  form  away 
from  the  facility)  to  be  afforded  more  importance  than  less 
inherently  risky  losses  (i.e.,  improper  handling  of  paper  me¬ 
dia).  In  practical  terms,  and  given  the  high  degree  of  “noise” 
present  in  possible  attempts  to  glean  useful  information 
through  the  examination  or  monitoring  of  an  automated  sys¬ 
tem,  the  sdale  reflects  variance  in  the  potential  that  an  adver¬ 
sary  could  gain  sufficient  data  in  an  appropriate  form  for 
automated  or  manual  analysis  to  actually  discover  something 
useful. 

Through  this  metric,  loss  is  expressed  as  an  abstract  number, 
The  actual  units  (CEALs)  were  sufficiently  obtuse  that  the 
term  'Abstracted  Units’  was  employed  in  reporting  the  values 
computed  for  various  situations.  While  the  scale  produced 
may  not  be  uniform,  since  more  serious  problems  may  not 
result  in  a  SLE  value  sufficiently  high  to  reflect  their  true 
import,  the  formula  has  resulted  in  a  reasonable  relative  rank¬ 
ing  of  problems,  which  was  the  intent.  It  also  satisfies  the 
basic  objectives: 

1.  Risks  associated  with  information  compromise  across  both 
discretionary  and  mandatory  controls  can  be  computed 
and  compared. 

2.  Situations  that  involve  exposure  of  classified  information 
to  personnel  with  no  necd-to-know-  will  rank  lower  (L=l) 
than  situations  associated  with  the  compromise  of  infor¬ 
mation  across  levels  (L.gt.l). 

3.  The  greater  the  number  of  classification  levels  crossed,  the 
greater  the  risk.  The  higher  the  bandwidth  (as  estimated 
via  the  'avenue’)  the  greater  the  risk. 

4.  Situations  involving  highly  classified  information  will  tend 
to  have  higher  risk  values  than  situations  involving  less 
highly  classified  information,  unless  the  volume  (as  esti¬ 
mated  via  the  exposure)  of  less  highly  classified  informa¬ 
tion  is  sufficiently  great  to  overcome  the  order  of  magni¬ 
tude  emphasis  of  classification  level. 

Mission  Dissatisfaction:  Some  ADI3  RA  methodologies  at¬ 
tempt  to  place  an  overall  value  on  the  ADP  organization,  or 
on  the  overall  value  of  the  user  organization.  In  the  military 
environment,  the  approaches  used  to  value  the  mission  have 
been  inappropriate,  resulting  in  dollar  values  for  “mission" 
that  are  much  too  high,  while  still  missing  the  vital  factors 
which  must  be  evaluated. 

Mission  values  are  sometimes  based  on  salaries  (of  all  person¬ 
nel),  equipment  costs,  or  annual  budget  allocations.  All  tech- 


niques  in  use  to  place  a  financial  value  on  “mission  satisfac¬ 
tion"  as  an  asset  result  in  enormous  numbers.  These 
numbers,  in  the  presence  of  even  relatively  minor  risks  to 
ADP  resource  availability,  result  in  potential  loss  values 
(based  on  the  percentage  of  potential  availability  unrealized  or 
percentage  of  mission  unsatisfied)  that  can  justify  nearly  any 
safeguard  that  at  all  reduces  the  potentials  for  system  down¬ 
time.  Vast  savings  appear  possible  'through  applying  expen¬ 
sive  countermeasures  to  reduce  downtime  potentials  by  min¬ 
uscule  amounts. 

For  commercial  organizations,  a  case  can  be  made  for  "mis¬ 
sion  satisfaction”  valuation  as  a  function  of  the  overall  organi¬ 
zation's  reliance  on  the  ADP  resource  for  revenue.  In  a  mili¬ 
tary  environment,  however,  the  competition  is  not  economic 
but  strategic.  The  value  of  a  command  and  control  system 
cannot  be  estimated  ns  dollars  per  hour  nor  can  downtime  be 
computed  in  terms  of  dollars  lost.  Downtime  losses  are  much 
greater  conceptually  than  in  financially. 

Any  metric  of  mission  satisfaction  must  consider  system  avail¬ 
ability.  Mission  satisfaction  for  an  ADP  organization  is  best 
described  as  the  highest  degree  of  system  availability  and  the 
lowest  degree  of  downtime.  Any  metric  which  attempts  to  por¬ 
tray  the  “losses”  associated  with  system  downtime  must  ap¬ 
preciate  the  realities  of  such  situations: 

1.  Downtime  losses  for  systems  differ  according  to  the 
criticality  of  the  resource  being  examined.  In  a  computer 
room  containing  multiple  resources,  only  a  subset  of  these 
resources  is  absolutely  critical.  Others  (development  sys¬ 
tems.  etc.)  could  become  unavailable  for  significant  peri¬ 
ods  of  time  without  appreciable  impacts  on  the  overall 
mission. 

2,  Downtime  losses  are  not  linear.  A  downtime  of  four  days 
is  much  more  than  four  times  as  damaging  than  a  single 
day  of  system  unavailability.  Secondary  losses  begin  to  ac¬ 
crue  as  organizations  which  rely  upon  the  resource  are  un¬ 
able  to  satisfy  their  needs.  Initial  per-hour  figures  may 
escalate  as  the  iength  of  unavailability  increases. 

Our  original  thoughts  led  us  to  the  following  formula  for 
losses  associated  with  system  downtime: 

ALL  =  AIT  *  M  *  (D*D) 

ALL  =  Annual  "Risk" 

AID  =  Frequency  of  the  situation  involving  downtime 
M  =  A  measure  of  the  criticality  of  the  system 
D  -  Downtime  length. 

Real  costs  (personnel  costs,  etc.)  were  estimated  as  dollars 
lost  with  an  appreciation  for  the  secondary  impacts  of  lengthy 
denials  to  various  users: 

Sl.I:  =  AIT:  *  D  *  (C  +  (Cl  +  C2  ...)) 

bLE  =  Dollar  costs  associated  with  downtime. 

C  =  Cost  per  unit  of  downtime  (Note  1.) 

Cl, 2  =  Cost  escalation  based  on  downtime  length. 

Note  1 .  Cost  per  unit  of  downtime  must  be  computed  based 
on  the  user  population  dependent  upon  the  resource.  This  user 
population  must  be  identified  based  on  the  users  of  informa¬ 
tion  produced,  not  merely  by  the  number  of  user  accounts. 

In  actual  use.  however,  the  survey  of  user  organizations  re¬ 
quired  to  actually  quantify  these  loss  potentials  proved  ex¬ 


tremely  complex  and  the  analysis  of  potential  per-hour  or  sec¬ 
ondary  costs  much  too  time-consuming  for  manual  tracking. 
Also,  the  rapid  ADP  RA  performed  to  testbed  this  metric  dis¬ 
covered  risks  applied  equally  across  all  surveyed  resources.  In 
a  more  detailed  analysis,  the  use  of  both  of  the  formulas  de¬ 
scribed  above  may  be  possible  and  appropriate.  In  the  rapid 
ADP  RA  performed,  however,  the  metric  for  downtime  losses 
was  considerably  simplified: 

SLE  (in  hours)  =  D  *  E 

ALE  (in  hours)  =  APE  *  SLE 

D  =  the  downtime  length  possible  (in  hours) 

E  =  the  percentage  of  system  resources  (normally  100%) 
afieeted  by  the  threat. 

Downtime  losses  are  computed  as  annual  hours-lost  figures 
for  all  situations  involving  the  potentials  for  downtime. 

“Abstracted  Units"  (for  information  compromise)  and 
“hours”  (for  denial  of  service  potentials)  results  in  three  rank¬ 
ings  of  problems  discovered  during  an  ADP  RA.  Problems  can 
be  ranked  according  to  those  with  the  greatest  potential  an¬ 
nual  costs,  those  with  the  greatest  potentials  for  information 
compromise,  and  those  with  the  greatest  potentials  for  system 
downtime.  These  rankings  are  useful  both  in  isolation  and  in 
comparisons  with  one  another. 

Different  problems  will  tend  to  be  shown  as  most  important 
according  to  each  metric.  Specific  situations  will  entail  losses 
in  more  than  one  metric.  For  example,  in  a  fire  the  systems 
may  need  to  be  shut  down  (downtime),  the  components  may 
burn  (dollar  losses),  and  unauthorized  personnel  will  have  to 
be  granted  access  to  the  computer  room  (information  compro¬ 
mise).  When  the  relative  rankings  of  these  problems  (accord¬ 
ing  to  the  various  metrics  involved)  arc  considered,  however, 
the  potentials  for  information  compromise  (based  on  a  rank¬ 
ing  in  the  face  of  other  information  compromise  potentials) 
quickly  diminish,  while  the  potentials  for  denial  of  service  and 
major  dollar  costs  (again  as  relatively  ranked  within  these 
scales)  become  apparent. 

Countermeasure  evaluations  are  also  different  in  an  ADP  RA 
model  which  employs  multiple  metrics.  The  traditional  dol¬ 
lars— saved  per  dollars-invested  cost-benefit  analyses  can  also 
be  “abstracted  units  saved"  per  dollar  invested  or  “hours  of 
downtime  saved"  per  dollar  invested.  Although  the  metrics 
employed  make  it  more  difficult  to  state  with  assurance  that 
“countermeasure  x  is  cost-effective,"  they  do  point  out  which 
countermeasures  are  more  relatively  cost-effective.  Again, 
relative,  not  absolute,  ranking  is  facilitated.  Comparing  prob¬ 
lems  or  countermeasures  across  metrics  is  purely  subjective.  It 
is  impossible  to  state  that  a  problem  in  information  compro¬ 
mise  is  more  or  less  severe  than  a  problem  with  availability  or 
real  costs.  Each  problem  is  important  on  its  own  merits. 

Risk  Management 

An  ADP  RA  is  useful  only  within  a  program  for  managing 
risk.  Risk  Management  is  a  responsibility  of  senior  manage¬ 
ment  in  all  ADP  installations  as  a  part  of  everyday  business. 
A  periodic  ADP  RA  supports  this  process  but  cannot  in  isola¬ 
tion  satisfy  the  need  for  a  systematic  program  for  Risk  Man¬ 
agement. 

Risk  Management  is  applied  to  any  system  that  faces  risks.  In 
software  development,  for  example,  one  of  the  major  manage¬ 
ment  programs  that  must  be  implemented  is  a  Risk  Manage- 
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mem  program  to  deal  with  the  threats  to  the  software  design 
and  development  process  [DoD-STD-2167],  Although  the 
management  of  an  ADP  installation  is  a  venture  with  signifi¬ 
cantly  more  inherent  risks  than  those  faced  during  software 
development,  few  installations  have  formalized  their  risk  man¬ 
agement  approaches.  As  a  result,  management  is  quickly 
overwhelmed  with  problems,  and  a  fire-fighting  approach  to 
ADP  resource  integrity  and  reliability  management  is  inevita¬ 
ble. 

Problem  identification  and  evaluation  occur  within  the  context 
of  specific  disasters.  The  minimum  actions  absolutely  neces¬ 
sary  to  resolve  current  situations  are  considered  and  acted 
upon  without  considering  root  causes  or  long-term  effects. 
This  approach  to  management  is  the  state-of-the-practice  in 
ADP  organizations  that  face  rapid  change  or  a  significant 
number  of  regular  threats.  Ironically,  it  is  exactly  this  environ¬ 
ment  that  would  benefit  most  from  a  formalized  risk  manage¬ 
ment  program. 

Effective  management  actions  in  any  system  correspond  to 
Risk  Management.  Management  determines  new  programs, 
initiatives,  and  corrective  actions  based  on  informal  percep¬ 
tions  of  the  severity  of  the  problems  addressed  or  averted. 
Even  high-level  budget  decisions  are  based  on  an  informal 
understanding  of  cost  vs.  benefits. 

Risk  Management  is  only  die  formalization  of  the  process  of 
effective  management.  Too  often,  problems  discovered  during 
one  ADP  RA  remain  to  be  rediscovered  during  the  next.  Too 
often,  problems  are  qualitatively  perceived  to  be  minor  until 
crises  occur.  Too  little  action  is  taken  too  late  in  response  to 
these  problems.  In  other  eases,  minor  problems  become  lost 
in  the  system  and  are  never  dealt  with  or  responded  to.  Prob¬ 
lems  or  risks  considered  too  minor  will  be  ignored,  Rapid 
evaluations  of  potential  risks  ignore  some  potential  impacts. 
The  extent  of  interdependencies  within  an  ADP  organization 
is  generally  accepted  but  poorly  understood.  In  some  cases, 
decisions  are  reached  regarding  the  need  to  respond  to  needs, 
but  effective  actions  to  implement  these  decisions  are  not 
taken  to  the  depth  necessary  for  effective  problem  resolution. 
The  details  of  implementing  policy  are  much  too  voluminous 
for  tlie  current  methods  of  control  and  monitoring.  ADP  RAs 
conducted  at  JDSSC  installations  have  revealed  numerous 
cases  of  incongruities  between  policy  and  actual  practice,  or 
between  high  level  decisions  and  low  level  implementations. 

Formalizing  the  existing  management  system  of  control  in  re¬ 
sponse  to  the  volume  of  problems  and  the  details  of  the  imple¬ 
mentation  of  responses  is  necessary  and  long  overdue.  To 
identify  how  that  formalization  can  be  achieved,  we  reviewed 
how  Risk  Management  works  in  well-defined  management 
controls  such  as  those  mandated  for  software  development. 
Risk  Management  consists  of  the  following  steps,  each  of 
which  is  conducted  within  a  formalized  tracking  system: 

1.  Risk  Identification.  Problems  are  identified  several  ways. 
ADP  RAs  identify  many  problems  in  a  short  time.  Other 
risks  are  identified  the  hard  way  -  after  the  fact.  Finally, 
many  problems  are  recognized  by  management  during 
day-to-day  operation. 

2.  Risk  Evaluation  The  probability  of  risk,  its  potential  im¬ 
pacts,  and  any  and  all  contributing  factors  must  be  identi¬ 
fied  as  quickly  and  as  completely  as  possible  after  a  risk 
has  been  identified. 


3.  Risk  Mitigation.  A  response  to  each  identified  risk  should 
be  decided  based  on  an  understanding  of  both  the  risk  and 
the  costs  of  alternative  responses.  Risk  Mitigation  is  the 
development  of  appropriate  resposes  to  known  risks. 

4.  Risk  Monitoring.  After  a  response  has  been  decided  upon, 
its  implementation  and  effectiveness  in  use  must  be  moni¬ 
tored  by  management. 

These  steps  remain  the  same  for  any  system  and  should  be 
quite  familiar  to  anyone  in  Configuration  Management.  A 
problem  reporting  system  is  required;  and  the  status  of  the 
analysis,  review,  approval,  and  implementation  of  counter¬ 
measures  (corrective  action)  is  regularly  recorded  and  re¬ 
ported.  Our  analyses  show  no  reason  to  modify  this  system, 
and  we  incorporated  it  directly  into  the  JDSSC  RAG. 

Risk  Management  aids  management  not  only  in  terms  of  what 
decisions  and  actions  must  be  taken  but  also  in  terms  of  how 
those  decisions  are  made.  Courtney’s  |un|common  sense  rec¬ 
ommendations  for  consideration  of  losses  before  countermea¬ 
sures  are  implemented  by  such  an  approach.  Once  estab¬ 
lished,  such  a  system  facilitates  control  to  a  greater  degree  of 
detail  than  is  humanly  possible  without  formal  tracking. 

JDSSC  11AG  METHODOLOGY 

Once  the  basic  model  of  risk  was  established,  the  other  re¬ 
quired  elements  of  the  methodology  were  developed  around  it. 
Summarization  methods  were  defined  from  both  the  defined 
defined  and  a  standardized  list  of  threats.  ADP  RA  results 
combinations  (the  prelude  to  true  network  ADP  RA  tech¬ 
niques)  were  defined  based  on  percentage  of  losses  due  lo 
threats  by  metrics,  an  approach  which  allows  different  ADP 
RA  scopes  in  different  locations.  Finally,  the  analysis  stages 
were  defined  to  allow  both  standard  problems,  those  typically 
found  or  expected  in  nearly  all  ADP  installations,  and  non¬ 
standard  problems,  those  unique  to  the  specific  environment 
and  which  may  have  never  before  been  encountered,  to  be 
identified  and  analyzed. 

Planning 

The  elements  of  the  scope  of  an  ADP  RA  should  be  agreed 
upon  in  advance  us  should  the  schedule  for  interim  reporting. 
The  results  of  this  planning  should  be  in  writing. 

The  first  phase  of  performance  defined  in  the  jDSSC  RAG  is 
scope  identification.  The  scope  of  an  ADP  RA  has  three  ele¬ 
ments;  physical,  technical,  and  administrative. 

Within  the  physical  scope,  the  specific  facilities  and  areas 
within  those  facilities  to  be  reviewed  are  identified.  The  list  of 
external  and  well  known  threats  to  the  facility  in  general  are 
agreed  upon  in  advance.  Areas  to  remain  unaddressed  (e.g., 
overall  facility  problems,  grounds,  etc.)  should  be  explicitly 
identified. 

It  is  unproductive  to  repeat  some  analyses  performed  many 
limes  before.  It  is  unlikely  that  moving  an  existing  computer 
facility  (the  only  possible  response  to  some  of  the  ‘‘risks"  con¬ 
sidered  in  many  ADP  RAs)  can  be  justified  based  on  external 
factors  like  the  risk  of  flooding,  earthquakes,  volcanoes,  or 
great  hurricanes.  Given  the  frequency  of  ADP  RAs  it  is  also 
unlikely  that  prior  analysis  results  in  these  areas  will  need  to 
be  adjusted  (for  continental  drift  or  the  global  greenhouse  ef¬ 
fect)  very  soon.  It  is  only  necessary  that  these  factors  be  un- 
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derstuod  once  -  before  the  facility  is  built.  The  JDSSC  RAG 
recommends  that  prior  analysis  results  be  consulted  for  this 
information  if  it  must  be  republished  at  all. 

Within  the  technical  scope,  the  actual  systems  to  be  reviewed 
are  agreed  upon,  as  is  the  depth  of  technical  analysis  to  be 
applied  against  each  system.  Within  JDSSC,  other  initiatives 
exist  to  review  risks  to  ADP  resources  and  to  grade  the  vul¬ 
nerabilities  of  technical  security  mechanisms.  Within  other 
agencies,  programs  for  contingency  planning,  application  cer¬ 
tification,  and  ADP  MIS  may  provide  significant  inputs  to 
these  types  of  analyses  if  they  are  necessary.  In  this  area,  it  is 
imperative  that  scoping  be  performed  based  on  an  under¬ 
standing  of  the  materials  available  for  analysis.  Attempting  to 
perform  application  certification,  inventorying,  or  contingency 
planning  within  an  ADP  RA  is  inappropriate.  Unless  sufficient 
tracking  mechanisms  exist,  reviews  of  the  technical  environ¬ 
ment  can  be  extremely  time-consuming, 

Finally,  the  organizations  to  be  reviewed  are  agreed  upon.  In 
specific  cases  (e.g.,  the  ADP  Security  organization,  the  Opera¬ 
tions  organization),  the  actual  organizational  structure  and  re¬ 
porting  mechanisms  can  become  threats  to  the  ADP  resource. 
While  many  may  disagree,  the  organization  is  itself  an  expen¬ 
sive  (and  continuing)  asset,  and  it  may  itself  be  at  risk  based 
on  threats  management  is  exposed  to. 

Qualitative  Review 

Once  the  scope  of  an  ADP  RA  has  been  established,  the  sec¬ 
ond  stage  of  performance  can  begin.  A  qualitative  review  of 
the  installation  is  performed.  Questionnaires  are  distributed  to 
site  personnel,  and  the  answers  to  those  questionnaires  should 
be  available  and  reviewed  prior  to  interviews.  Site  reviews  and 
tours  are  required  for  all  involved  in  an  ADP  RA. 

To  a  large  degree,  the  JDSSC  RAG  methodology  draws  from 
the  already  available  successful  and  positive  elements  of  other 
methodologies  for  .ADP  RA.  LAVA's  excellent  questionnaire 
is  incorporated,  as  are  the  questionnaires  from  AR  380-380, 
the  WWMCCS  RAG,  and  the  NASA  ADP  Risk  Analysis 
Guideline.  The  JDSSC  RAG  provides  guidance  as  to  the  most 
appropriate  audiences  for  each  element  of  each  questionnaire. 
The  areas  where  contentions  or  differences  exist  between  dif¬ 
ferent  copies  of  identical  questionnaires  can  provide  valuable 
insights  about  where  problems  exist  within  an  .ADP  installa¬ 
tion. 

All  involved  in  an  ADP  RA  effort  are  required  to  tour  the 
facility  and  make  their  feelings  and  impressions  known  to  the 
other  members  in  writing.  While  all  ADP  RA  members  can  be 
expected  to  see  similar  things  in  these  unstructured  reviews, 
each  will  see  each  thing  differently  and  will  spot  problems 
missed  by  all  others  who  perform  the  same  review.  This 
'touch  and  feel'  element  of  an  ADP  RA  cannot  be  eliminated 
and  is  a  iarge  part  of  the  value  provided  through  the  analysis. 
ADP  RA  remains  dependent  upon  the  people  performing  the 
analysis.  Personnel  with  the  right  backgrounds  and  level  of 
generalized  experience  required  are  needed. 

Structured  interviews  are  conducted  from  the  bottom  up  in  all 
reviewed  organizations  (as  well  as  within  organizations  not 
being  specifically  reviewed),  It.terviewing  from  the  bottom  up 
maximizes  the  productivity  wi  :h  personnel  at  higher  points  in 
an  organizational  structure  where  experience  is  concentrated. 
Interviews  are  conducted  not  to  learn  of  the  standard  threats 
to  the  ADP  resource,  which  should  have  been  identified 
through  the  questionnaires,  but  to  learn  of  other  and  non¬ 
standard  threats  the  ADP  resource  is  exposed  to.  The  JDSSC 


RAG  provides  a  starting  point  for  this  stage  of  the  analysis, 
including  a  structure  for  interviewing  that  concentrates  on  the 
identification  of  duties,  responsibilities,  and  reporting  struc¬ 
ture. 

Qualitative  reviews  employ  standard  mandates,  including  the 
EDP  Auditors  Association's  Control  Objectives  -  1980.  Using 
established  mandates  limits  the  types  of  subjective  judgements 
that  can  lead  to  contention.  Within  JDSSC,  analyses  are  a'so 
made  against  established  mandates  including  JCS  Publication 
22  and  DoD-5200,28, 

Quantification  and  Analysis 

After  the  qualitative  review  is  completed,  the  quantification 
process  begins.  Standardized  threats  and  national  statistics  for 
those  threats  are  employed.  Most  problems  have  well-known 
countermeasures.  Those  without  well-known  responses  re¬ 
quire  more  in-depth  analysis. 

Each  problem  is  associated  to  a  set  of  threats  and  recorded  on 
standardized  forms.  The  potential  losses  to  each  threat  (in 
each  appropriate  metric)  are  computed  and  recorded. 

Countermeasures  are  analyzed  in  terms  of  their  impact  on  the 
losses  to  each  threat  in  each  metric.  Note  that  the  countermea¬ 
sures  are  evaluated  on  their  own  merits  and  independently  of 
problem-specific  losses.  Problem-specific  loss  estimation  is 
useful  only  for  problem  ranking.  The  mapping  between  coun¬ 
termeasures  and  problems  is  less  than  exact;  one  problem 
may  require  multiple  countermeasures,  one  countermeasure 
may  apply  to  a  number  of  specific  problems. 

Summarization  and  Abstraction 

The  set  of  quantified  loss  potentials  and  countermeasure 
analyses  are  input  to  the  final  stage  of  the  analysis  -  abstrac¬ 
tion  and  summarization.  The  results  of  this  stage  are  used  to 
report  the  ADP  RA  to  management  and  to  allow  ADP  RAs  to 
be  combined  across  installations. 

Problem-specific  losses  are  first  combined  to  produce  losses 
by  threat  within  metric  during  the  last  phase  of  the  analysis 
described  above.  Next,  the  percentage  of  loss  attributable  to 
each  threat  within  metric  is  defined.  This  effort  should  also 
result  in  the  identification  of  the  most  serious  problems  (for 
major  threats)  within  each  metric.  The  summarization  report 
contains  these  percentage  of  loss  by  threat  within  metrics  fig¬ 
ures  and  illustrates  them  by  summarized  descriptions  of  the 
most  serious  problems  for  each  metric.  Countermeasures 
which  are  the  most  cost-effective  are  also  contained  in  the 
summary  report. 

The  summarization  report  should  contain  all  of  the  informa¬ 
tion  required  for  ADP  RA  results  combination.  In  practice,  the 
JDSSC  RAG  may  need  to  be  adjusted  to  increase  or  change 
the  information  contained  in  the  summary  report. 

Pie  charts  were  used  in  the  testbed  ADP  RA  to  illustrate  the 
losses  attributable  to  major  threats  in  each  metric.  A  list  of 
the  percentage  of  loss  by  threat  is  listed  to  contain  threat  per¬ 
centages  too  minor  to  be  visible  within  tnew  pie  chart.  While 
graphical  representation  is  seen  as  an  important  feature  of  the 
summary  report,  other  representations  of  the  information  are 
still  being  researched. 

FUTURE  EXPANSIONS 

The  JDSSC  RAG  was  delivered  in  December  of  1987.  It  re¬ 
mains  far  from  optimal,  especially  in  terms  of  the  level  of 
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guidance  it  provides  to  inexperienced  personnel.  Future  ef¬ 
forts  will  concentrate  on  making  the  JDSSC  RAG  easier  to  use 
in  locations  where  specific  expertise  in  ADP  RAs  is  not  avail¬ 
able,  such  as  high  security  environments  and  remote  loca¬ 
tions.  Other  areas  for  research  include  the  areas  identified 
below. 

Combinational  APP  RA  Results 

During  1988  and  1989,  JDSSC  will  begin  to  employ  its  RAG 
during  other  ADP  RAs.  As  additional  ADP  RA  results  are 
produced,  the  means  for  combining  and  summarizing  ADP 
RA  results  contained  in  the  RAG  will  be  revised  and  demon¬ 
strated.  Combining  ADP  RA  results  is  a  capability  prerequi¬ 
site  to  effective  ADP  Security  management  within  JDSSC. 

Expansions  to  a  Network  ADP  RA  Model 
However,  the  combining  of  specific  ADP  RA  results  is  not  the 
only  prerequisite  to  the  performance  of  Network  ADP  RAs. 
Networks  are  exposed  to  threats  not  applicable  to  ADP  re¬ 
sources  in  isolation.  Many  of  the  elements  of  the  JDSSC  RAG 
(e.g.,  its  standardized  threat  nomenclature,  etc.)  must  be  re¬ 
vised  or  extended  before  application  to  a  network  is  possible. 

Analyses  of  “risk”  in  an  automated  network  environment 
based  on  the  trustedness  of  its  systems  versus  the  clearance 
levels  of  its  users  (the  NCSC's  Yellow  Books)  must  also  be 
considered.  It  must  be  accepted,  however,  that  networks  incor¬ 
porating  all  trusted  elements  remain  in  the  future  for  JDSSC. 
In  the  largest  part,  both  its  networks  and  its  systems  in  isola¬ 
tion  remain  unevaluated  and  unccrtifiable.  The  lack  of  trusted 
components  is  not,  however,  in  any  way  slowing  the  move¬ 
ment  of  agencies  like  JDSSC  towards  networking.  Security 
mechanisms  are  being  retrofitted  into  commercially  available 
networking  systems  as  an  alternative  to  no  security  at  all.  As  a 
result,  the  need  for  Network  ADP  RAs  is  extremely  high. 

Automation 

Automation  severely  constrains  the  ability  to  modify  a  meth¬ 
odology  in  development.  As  a  result,  we  have  resisted  the  im¬ 
pulses  to  automate  too  much  of  the  methodology  too  quickly. 
However,  several  elements  of  the  methodology  are  now  ready 
for  such  a  process.  We  intend  to  begin  by  automating  the 
best-known  part  of  the  methodology,  quantification  and  sum¬ 
marization,  along  with  an  automated  set  of  questions  in  spe¬ 
cific  areas.  Implementation  will  concentrate  on  the  ability  to 
to  transmit  risks,  problems,  countermeasure  implementation 
reports,  and  security  postures  between  various  field  locations 
and  a  central  controlling  authority  -  the  model  of  ADP  secu¬ 
rity  in  the  military  environment. 

CONCLUSIONS 

The  JDSSC  RAG  is  still  in  its  beginning  and  conceptual  design 
stages.  More  work  is  needed  before  it  becomes  a  useful  tool 
for  JDSSC  ADP  Security  management.  It  provides  some  possi¬ 
ble  responses  to  some  of  the  more  difficult  questions  facing 
risk  analysts  in  a  classified  ADP  environment.  In  the  absence 
of  experienced  ADP  RA  analysts,  means  must  be  found  to 
communicate  exactly  what  must  be  done  to  identify  how  re¬ 
sults  are  to  be  produced.  JDSSC  remains  committed,  however, 
to  seeking  answers  to  these  questions  through  the  develop¬ 
ment  of  new  methods.  Existing  methods  and  tools  have  not 
met  their  needs.  The  approach  conceptualized  above  may  pro¬ 
vide  the  starting  point  for  analyses  to  solve  the  critical  prob¬ 


lems  facing  ADP  management  officials  in  the  military  envi¬ 
ronment. 
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Abstract 

As  the  number  and  complexity  of  computer  systems  grow,  the  need 
for  useful  tools  for  perfonning  risk  assessments  of  these  systems  will 
become  more  pressing.  In  recent  years,  there  have  been  several  attempts  to 
automate  the  risk  assessment  process  through  the  use  of  questionnaires  and 
menus.  Some  of  these  are  implemented  on  personal  computers  for  wide 
availability.  Although  these  techniques  offer  an  improvement  over 
completely  manual  methods,  they  arc  often  either  cumbersome  to  use 
because  of  the  wealth  of  information  that  must  be  laboriously  extracted,  or 
inadequate  for  deriving  a  sufficiently  accurate  risk  assessment, 

We  have  been  Investigating  a  new  artificial  intelligence-based  approach 
to  standardizing  and  automating  the  risk  management  process  that  will 
enable  the  analyst  to  produce  risk  assessments  that  are  less  costly,  more 
uniform,  and  less  prone  to  subjectivity.  Central  to  our  approach  is  the 
concept  of  determining  the  risk  to  information  as  It  is  used  In  the  system, 
rather  than  the  replacement  cost  of  hardware  and  facilities.  A  four-level 
abstraction  hierarchy  for  classifying  system  components  and  assets  Is  used 
as  tlie  basis  for  constructing  system  models.  We  then  determine  risk  to 
informational  assets  according  to  three  primary  criteria  of  security  value: 
confidentiality,  integrity,  and  availability.  A  model  of  information  usage  in 
tlie  system  is  then  developed  to  analyze  Hie  security  risk  for  die  complete 
information  system. 

Intrnrliictlnn 

The  development  of  an  effective  security  program  is  critically 
dependent  on  the  application  of  risk  management  to  die  initial  design, 
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subsequent  modificadons,  and  ongoing  monitoring  of  a  system. 

Therefore,  the  need  for  useful  risk  assessmenls  and  tools  will  become 
more  urgent  as  Ihc  number  and  complexity  of  computer  systems  grow. 
Although  a  variety  of  methods  have  been  proposed  and  are  currendy  in  use 
for  performing  risk  analysis  [1,2],  many  arc  difficult  to  apply  efficiently. 
In  recent  years,  there  have  been  several  attempts  to  automate  die  risk 
assessment  process  Uirough  the  use  of  computer-driven  questionnaires  and 
menus.  Some  of  these,  including  RiskPAC,  RiskCALC,  RISKA,  and 
LAVA/CS  [3|.  are  implemented  on  personal  computers  for  wide 
availability.  Although  these  techniques  offer  an  improvement  over 
completely  manual  methods,  they  are  often  cither  cumbersome  to  use 
because  of  die  wealth  of  information  that  must  be  laboriously  extracted  via 
lengthy  questionnaires,  or  inadequate  for  deriving  a  sufficiently  accurate 
risk  assessment  due  to  their  focus  on  component  replacement  cost. 

With  a  goal  of  enabling  risk  assessments  that  arc  less  costly,  more 
uniform,  and  less  subjective,  we  have  been  investigating  a  new  approach 
to  standardizing  and  automating  the  risk  management  process,  which 
incotporates  artificial  intelligence  techniques  of  representation  and 
reasoning  to  model  a  computer  system,  its  components,  and  the  asset 
usage  within  the  system,  The  approach  draws  on  research  in  artificial 
intelligence,  which  has  led  to  new  mcdiods  of  representing  symbolic 
information  at  different  levels  of  abstraction.  Frame-based  and  object- 
oriented  systems,  in  particular,  are  extremely  powerful  and  versatile 
techniques  for  describing  entities  symbolically  and  embedding  them  into 
hierarchies  of  related  entitles.  We  ure  exploring  the  use  of  these  methods 
for  constructing  representations  of  a  computer  system's  components,  so 
that  we  can  mode!  their  interactions.  In  addition,  we  will  be  using 


Figure  1.  Architecture  tor  a  knowledge-based  risk  management  system. 
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advanced  techniques  for  reasoning  about  imprecise  and  uncertain 
information,  such  as  the  theory  of  fuzzy  sets,  to  better  describe  the  risk 
involved  in  a  complex  environment. 

We  have  developed  the  concept  for  a  knowledge-based  expert  system 
to  assist  in  the  risk  management  process,  The  current  proposed 
architecture  for  our  system,  described  in  [5],  is  shown  in  Fig.  1.  This 
approach  has  these  primary  features: 

•  It  is  based  on  multiple,  high-level  computer  graphic  models  of  the 
system,  so  that  fewer  detailed  questions  arc  required,  many 
relationships  can  be  derived  automatically,  and  all  of  the  input  data 
can  be  checked  for  consistency. 

•  It  minimizes  the  requirement  for  sophisticated  risk  management 
knowledge  and  leads  to  more  uniform  results. 

•  It  considers  all  aspects  of  comprehensive  risk  management, 
drawing  on  multiple  underlying  knowledge  bases  for  expertise 
about  the  domain. 

Central  to  the  design  is  the  security  schematic,  which  is  a  model  of  the 
security  requirements  and  attributes  of  the  system  based  on  an  underlying 
model  of  the  risk  management  process.  The  requirements  arc  broken 
down  into  the  three  basic  or  primary  criteria  of  security  value  — 
confidentiality,  integrity,  and  availability  —  and  drive  all  of  the  system's 
reasoning.  The  underlying  knowledge  bases  or  hierarchical  data  bases 
contain  taxonomies  of  risk  entities,  such  as  assets,  threats,  vulnerabilities, 
and  countermeasures,  as  well  as  banks  of  questions,  similar  to  the  ones 
found  in  automated  questionnaires  such  as  those  used  by  LAVA/CS. 

These  questions  may  be  selected  dynamically  by  the  system  as  needed, 
rather  titan  mechanically  through  a  laborious,  step-by-step  process.  The 
reasoning  module,  or  inference  engine,  controls  the  operation  of  the 
system,  and  includes  tite  capacity  for  generating  and  analyzing  security 
requirements;  building  and  maintaining  models;  selecting  appropriate 
parameters,  questions,  and  data  from  the  knowledge  bases;  and  analyzing 
the  trade-offs  necessary  for  efficiently  managing  risk.  Despite  all  this 
complexity,  the  user  interface  portion  of  the  system  presents  a  palatable  set 
of  views  of  the  system's  model  and  analysis,  as  well  as  dialog  windows, 
which  allow  the  option  of  querying  or  modifying  any  part  of  the 
knowledge  bases  tcxiually  or  graphically. 

Informational  Aa«u 

Traditionally,  risk  assessments  have  focused  on  the  replacement  value 
of  the  hardware  and  facilities  of  a  system.  Indeed,  the  risk  assessment 
methodologies  sanctioned  by  various  government  agencies,  such  as  that 
described  in  FIPS  PUB  65  (6),  are  also  based  on  this  approach,  Although 
it  Is  undeniably  important  to  Include  direct  physical  losses  In  a 
comprehensive  risk  assessment,  the  greatest  risks  to  any  computer  system 
by  far,  and  those  that  are  hardest  to  quantify,  are  the  compromise  of  the 
informational  content  of  the  system,  rather  than  the  system  components 
themselves.  We  have  therefore  concentrated  on  quantifying  and 
expressing  the  risk  to  the  informational  assets  of  a  computer  system,  We 
view  the  definition  and  evaluation  of  infoimatlcnal  assets  as  central  to  the 
task  of  adequately  assessing  system  risk. 

Informational  assets  (which  we  shall  sometimes  refer  to  as  simply 
assets)  refer  to  the  actual  knowledge  or  information  that  is  valuable  to  the 
organization,  such  as  customer  names  and  addresses,  not  tire  instantiations 
of  that  Information,  such  as  data  files  containing  customer  names  and 
addresses,  The  distinction  is  a  subtle  but  important  one.  We  are 
concerned  with  ensuring  the  security  of  the  information,  rather  than  a 
particular  instantiation  of  it,  For  instance,  if  a  disk  containing  records  of 
recent  transactions  crashes  and  Is  lost,  the  Information  may  be  recoverable 
from  a  backup  copy,  or  by  reconstruction  of  the  lost  records. 


As  mentioned  above,  the  security  requirements  of  an  organization's 
assets  can  be  classified  into  three  primary  criteria  of  security  value; 
confidentiality  (protecting  an  asset  from  harmful  disclosure),  Integrity 
(protecting  an  asset  from  modification),  and  availability  (assuring  that 
information  is  available  when  needed).  The  value  of  a  primary  criterion  of 
a  particular  instantiation  of  an  asset,  as  it  were,  may  or  may  not  correspond 
to  the  value  of  the  primary  criterion  of  that  asset  Itself.  So,  for  instance,  in 
the  example  used  above,  assurance  of  the  availability  of  the  particular  data 
file  containing  recent  transactions  is  not  necessary  in  order  to  assure  the 
availability  of  the  information  itself, 

The  intuitive  inverse  correlation  of  availability  and  confidentiality  can 
be  demonstrated  clearly  using  a  particular  attribute  of  the  instantiation  of  an 
asset  according  to  our  formulation,  For  example,  if  we  consider  the 
attribute  of  number  of  copies  of  an  asset,  we  can  show  that  the  risk  to 
confidentiality  rises  as  the  number  of  copies  rises,  while  the  risk  to 
availability  declines,  as  illustrated  In  Fig.  2a.  Integrity  risk  has  a  more 
complex  curve,  shown  in  Fig.  2b.  Hie  integrity  of  an  asset  is  at  greater 
risk  of  compromise  as  the  number  of  copies  rises  (in  the  absence  of 
countermeasures,  such  as  matching  the  copies  against  a  master),  yet  the 
risk  also  increases  as  the  number  of  instantiations  approaches  zero,  since  it 
cannot  be  lower  than  the  risk  to  availability. 


Figure  2a,  Risk  trade-offs  based  on  number  of  Bottware 
Ins.antlatlone  of  an  Informational  asset. 


An  asset  has  a  number  of  attributes  that  must  be  specified  and 
understood  clearly  before  its  informational  value  can  be  established.  Tnesc 
include  attractiveness  to  threat  agents,  perceived  value,  possible  outcomes 
(undesirable  events  that  can  befall  it),  and  the  sum  of  all  other  attributes,  Its 
actual  compromise  value,  which  is  an  expression  of  how  much  is  lost  if  its 
security,  as  measured  by  one  of  the  primary  criteria,  is  compromised.  To 
determine  asset  value,  we  must  develop  a  methodology  for  considering 
these  tightly  interrelated  attributes. 
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Figure  3.  Abstraction  levels  ot  assets  and  components. 


INFORMATION  Types: 


Names,  dates,  figures, 
documents,  ideas,  programs, 
processes 


Compromise  Value 
Security  requirements 

•  Confidentiality 

•  Integrity 

•  Availability _ 
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SOFTWARE 

Functions: 

Iiaoster 

Transformation 

Storage 

Types: 

Systems 

Applications 

Data 

Files 

Records 

MEDIA 

Functions: 

Storage 

Types: 

Tapes,  hard  disks,  floppy 

disks,  printouts,  paper, 

punch  cards 

HARDWARE 

Functions: 

Transfer 

HflHftuFtt'inir-iirciTHK 

Types: 

Tape  and  diskdrives, 
workstations,  terminals, 
printers,  cables,  wires 

Processors 

Abjjtravti.utt..Lmls-aLAfia:U  and  Cmaaimgals 

Although  informational  assets  are  tlte  primary  entities  needing 
protection,  and  drive  die  determination  of  security  requirements,  we  cannot 
assess  the  risk  to  assets  directly,  nor  protect  them  directly.  Instead,  we 
must  consider  the  system  and  tire  environment  in  which  the  information  is 
processed. 

Accordingly,  wc  have  developed  a  four-level  abstraction  hierarchy  Tor 
classifying  assets  and  system  components,  illustrated  in  Fig.  3,  At  die 
lowest  level  are  the  hardware  components  of  die  system,  such  as  the  CPU, 
tape  and  disk  drives,  printers,  and  cables.  These  are  generally  fixed  in 
place  physically,  and  are  die  base  on  which  everydiing  else  operates.  The 
next  level  comprises  media  components,  which  sit  on  die  hardware 
components,  but  tend  to  be  less  fixed.  Examples  of  media  components  arc 
tapes,  disks,  and  printouts.  The  third  level,  software,  includes  files, 
databases,  and  programs,  which  exist  in  die  environment  provided  hy  die 
hardware  and  media  levels.  At  die  highest,  most  abstract,  level  are  die 
informational  assets  themselves.  It  is  at  this  level  dial  asset  value  and 
security  requirements  arc  defennined. 

Informational  assets  can  have  instantiations  at  each  of  die  component 


levels,  For  instance,  customer  names  and  addresses  tinfomiadon)  may  be 
recorded  in  a  database  (software),  stored  on  a  disk  (metlium),  and  accessed 
through  a  disk  drive  (hardware).  Threats  and  dieir  actions  operate  in  the 
environment  of  die  component  levels,  and  countcnneasures  are 
implemented  there  as  well,  aldiough  informational  assets  may  be  the 
ultimate  targets  of  those  threats. 

It  is  also  useful  to  classify  system  components  according  to 
functionality  with  respect  to  assets  processing  in  die  system.  The 
functions  perfonned  by  an  information  system  can  be  divided  into  diree 
broad  categories:  storage,  transfer,  and  transformation.  If  we  are  to  model 
asset  usage  in  the  system,  It  Is  essential  to  understand  dicse  diree 
functions,  die  relationships  and  differences  between  them,  and  die  ways  in 
which  they  are  perfonned  by  the  system's  components. 

Figure  4  depicts  a  matrix  showing  the  different  functions  associated 
widi  various  components  at  the  diree  lower  abstraction  levels.  More 
information  is  contained  here  than  is  immediately  apparent.  For  instance, 
aldiough  both  hardware  and  media  components  are  used  for  storage, 
hardware  storage  typically  tends  to  be  short  tenn,  whereas  media  storage 
implies  a  longer  tenn.  Storage  in  sollwarc,  meanwhile,  lias  a  different 
meaning,  because  die  software  component  used  for  storage  resides  in  a 
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Figure  4.  Functional  component  matrix. 
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hardware  or  media  component.  These  distinctions  arc  invaluable  in 
modelling  system  usage  and  in  assessing  the  risk  associated  with  the 
system  and  the  methods  cl' minimizing  that  risk. 


important  aspect  of  this  activity  is  the  identification  of  asset  transfer 
and  utilization.  The  information  from  this  stage  is  used  to  derive 
asset  compromise  cost  by  component. 


Based  on  the  preceding  discussion  of  assets  and  components,  it  is 
clear  that  an  accurate,  comprehensive  risk  assessment  for  informational 
assets  must  entail  a  model  of  the  components  in  a  computer  system  and 
their  interactions,  overlain  by  an  asset  usage  model  that  describes  die 
processing  of  information  by  the  system,  Likewise,  an  automated  system 
for  assisting  in  the  risk  management  process  should  lie  capable  of 
constructing  and  utilizing  such  models. 

We  are  currently  developing  the  framework  for  such  a  system.  A 
required  step  is  to  create  a  component  libraty,  consisting  of  data  structures 
Unit  represent  knowledge  about  system  components.  As  die  information 
contained  in  the  library  becomes  richer,  die  skill  of  die  system  will 
improve.  At  a  basic  level,  however,  library  entries  must  include  die  type 
and  function  of  the  component  widt  respect  to  bodt  die  processing  of  assets 
and  its  links  to  odicr  system  components. 

The  user  of  such  an  automated  system,  as  we  envision  it,  would  select 
predefined  components  from  the  library  arid  link  diem  together  into  a 
lunctional  and  physical  model  of  die  system  using  existing  CAD/CAM 
tools,  which  provide  graphic  displays  that  facilitate  interaction  and  enhance 
understanding.  A  Itcmalively,  die  user  would  be  able  to  define  novel 
com|Xincnts  and  include  litem  in  the  model,  as  well  as  enter  diem  into  the 
library. 

In  addition  lo  a  library  of  system  components,  it  will  be  necessary  to 
develop  data  structures  to  represent  the  hifonmuionai  assets  diut  need 
prelection  front  compromise.  With  these,  the  user  would  be  able  to 
construct  an  iiilonnuiion  liow  model  to  illustrate  the  processing  of  assets 
through  die  system,  which  would  be  proscnied  as  another  graphical  view 
of  the  system.  The  diree  graphical  views  described  here  are  illustrated  in 
Fig.  3. 


FUNCTIONAL  PHYSICAL  INFORMATION  FLOW 


Figure  5.  Ussr  views  of  system  models. 


The  automated  system  would  dien  apply  the  user's  model  of  system 
design  and  asset  usage ,  combined  with  its  knowledge  of  the  component 
characteristics  and  die  security  requirements  of  die  assets,  to  identify 
component  vulnerabilities  widt  respect  to  die  assets  and  to  propose 
adequate  countermeasures  for  dealing  with  diem. 

We  summarize  here  die  stages  of  risk  management  according  to  the 
above  incdiodology: 

1.  Building  a  model  of  the  system  under  review  —  -  this  is  done 
graphically,  using  schematics  and  other  diagrams.  In  diis  stage, 
predefined  components  are  selected  from  existing  data  bases, 
additional  novel  components  dial  may  be  present  arc  defined,  and 
the  components  tire  structured  into  a  complete  system  definition, 
which  includes  the  functions  of  and  relationships  between 
components.  The  system  is  Uicn  checked  for  consistency  and 

2.  Identifying  the  assets  processed  by  the  system  and  their  value, 
tithing  into  account  the  consequential  value  of  asset  compromise  — 
the  informational  assets  processed  by  the  system  arc  Identified  and 
assessed,  and  die  outcomes  of  their  compromise  are  specified,  An 


3 .  identifying  vulnerabilities  associated  with  the  system  components 
and  countermeasures  for  neutralizing  or  minimizing  those 
vulnerabilities  —  component  vulnerabilities  that  expose  the  assets 
they  process  arc  defined,  and  countermeasures  (CM)  arc  identified 
that  can  be  used  to  reduce  or  eliminate  asset  exposure. 

4.  Identifying  threats  to  the  system  assets  —  based  on  knowledge  of 
threat  agents  and  their  actions,  specific  threats  arc  identified  that  may 
exploit  a  vulnerability  of  the  system  to  compromise  the  security  of 
un  asset.  Included  aw  both  non-human  or  unintentional  direats  such 
as  component  failure,  and  intentional  threat  actions  such  as 

5 .  Analyzing  the  likelihood  and  severity  of  possible  threat  paths,  and 
identifying  the  outcome,  of  threat  actions  —  possible  and  likely  paths 
by  which  threats  could  access  and  compromise  assets  arc  analyzed, 
along  with  the  outcomes  und  consequences  ensuing  from  each. 

From  lids  analysis,  overall  risk  of  compromise  to  system  assets  can 
be  asssessed. 

6.  Presenting  a  summary  if  system  risk  that  offers  safeguard  packages 
described  In  terms  of  costs  and  benefits  —  die  results  of  the  risk 
analysis  are  presented  lo  die  user  In  die  fonn  of  a  risk  summary  and 
graphic  descriptions  of  various  ..aleguard  alternatives  with  Uieir 
costiliencfit  trade-offs.  Specific  situations  representing  die  highest 
risk  arc  Identified. 

The  stages  of  model-based  risk  management  are  portrayed  in  Fig,  ft. 

In  die  next  section,  we  present  u  description  of  a  knowledge-based  system 
that  assisis  in  this  process,  with  some  suggestions  for  its  implementation. 


Figurn  6.  Modei-bas«d  risk  management. 

A  Knowledge-Based  System  for  Modelling  Asset  Usaite 

Useful  methods  for  symbolically  representing  knowledge  have 
evolved  from  research  in  artificial  intelligence.  In  an  object-oriented 
representation,  each  entity  is  represented  as  un  object  with  various 
attributes.  But,  each  object  may  be  a  member  of  one  or  more  classes  of 
objects  which  have  attributes  of  tiieir  own,  and  die  object  classes  arc  also 
objects,  and  may  thus  be  members  of  other  classes,  und  so  on.  This 
formalism  allows  us  to  build  hierarchies  of  objects,  which  can  he 
constructed  to  correspond  10  actual  hierarchies  of  entities  in  the  domain 
being  described.  Objects  may  inherit  attributes  or  values  from  Uieir  parent 
classes,  and  default  values  may  be  specified  for  die  attribute  values. 
Various  processing  methods  can  be  used  with  objects,  including  triggering 
actions  based  on  die  value  of  the  object's  attributes. 
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We  are  currently  designing  an  object-oriented  system  for  rcprcscni  mg 
and  reasoning  about  system  components  and  asset  usage.  Hardware, 
media,  and  software,  as  discussed  above,  arc  examples  of  object  classes  in 
such  a  representation.  One  attribute  shared  by  the  members  of  all  of  these 
classes  is  function,  i.c. ,  storage,  transfer,  or  transfonnation.  Conversely, 
certain  classes,  such  as  hardware,  may  have  attributes,  such  as  physical 
description,  size,  capacity,  and  location,  that  are  not  shared  by  ('liter 
classes.  The  value  of  specific  attributes  also  may  vary  within  an  object 
class.  Those  objects  with  similar  attributes  can  be  grouped  into  subsets. 

Tlte  input  and  output  pons  arc  critical  attributes  in  representing  the 
transfer  of  assets  within  a  system.  At  Hie  hardware  level,  these  may  refer 
to  actual  hardware  [wrts  or  terminals  of  the  component,  whereas  at  the 
media  level,  they  refer  to  the  hardware  on  which  the  media  reside,  and  for 
software,  to  the  input  and  output  capabilities  of  Hie  softwate  component. 
Integrating  die  representation  of  die  attributes  of  die  various  component 
levels  is  die  key  to  creating  an  asset  usage  model  of  the  system. 

We  arc  designing  die  system  so  that  it  will  lead  die  user  through  die 
risk  management  process  by  constructing  a  model  or  set  of  models  of  die 
system  under  consideration,  including  die  physical  layout,  functional,  and 
information  How  diagrams  described  above.  Since  the  graphical  objects  in 
these  views  arc  representations  of  die  underlying  objects  of  the  knowledge 
base,  die  user  is  actually  building  a  model  of  die  system  in  lhe  computer's 
memory.  Tile  user  would  tie  able  to  switch  from  one  view  lo  .mother at 
will,  ami  modify  or  query  die  knowledge  base  Interactively  from  any  view, 
wluic  die  syslem  would  guide  the  user  dirougli  diis  model-building  phase 
and  check  lor  missing  or  inconsistent  mlonnation.  The  expert  system 
would  use  die, sc  graphic  models  to  derive  information  about  the  security  of 
die  system,  inferring  most  relationships  directly.  It  would  dten  walk  die 
user  through  a  dialog  requesting  additional  information  not  explicit  in  those 
views  and  suggest  values  for  risk  management  parameters.  This  niediod 
ensures  tlte  accuracy  and  consistency  of  die  analysis,  facilitates 
modification,  and  closely  resembles  die  method  risk  management 
professionals  use  to  perform  risk  assessments. 

impk-miiimuidii  Eauunalii 

We  now  present  a  specific  example  to  illustrate  how  the  proposed 
system  might  work.  Tlte  knowledge  base  may  include  a  hierarchical 
structure,  suclt  as  dial  in  f  ig,  V  showing  the  representation  of  knowledge 


about  networks.  Each  of  the  specific  network  implementations  (leaf 
nodes)  would  have  a  component  library  entry,  and  the  higher  level  nodes 
would  have  library  templates  filled  in  only  to  the  appropriate  level  of  detail. 
Examples  of  portions  of  these  library  entries  arc  shown  in  Figs.  8a,  b,  and 
c.  Note  that  each  successive  node  down  the  hierarchy  inherits  information 
from  its  parent  node.  Thus,  the  knowledge  engineer  who  builds  the 
hierarchy  docs  not  have  to  enter  all  the  information  for  cacli  node,  reducing 
effort  and  the  potential  Tor  entry  errors.  Additional  and  more  specific 
information  can  be  added  for  particular  nodes,  as  shown. 

Type  of  Network: 

Baseband 

Broadband 

CHANNEL  type: 

Coaxial  cable 
Twisted  pair 
Radio 

Fiber  optic 

Number  of  Stations: 

DATA  RATE: 

>  Mbps 
5  Mbps 
10  Mbps 
20  Mbps 

Figure  8a.  Network  object  entry. 

Suppose  the  user  Indicates,  ptcrliaps  by  clicking  the  mouse  on  a 
network  icon  on  the  main  model-building  display,  Dial  tlte  system  under 
review  Includes  a  network.  Tlte  ex|x:rt  syslem  could  ilien  present  a  menu 
of  network  types.  It  might  even  display  this  in  Die  form  shown  in  Fig.  7, 
with  common  defaults  highlighted  as  indicated,  and  allow  die  user  to 
browse  through  the  tree  and  select  a  node. 

If  iite  user  Ilien  selects  the  node  labelled  '’Ethernet,"  die  network 
specified  by  the  user  as  being  part  of  tlte  system  schematic  model  is  now 
identified  as  an  Ediemct,  and  is  associated  widi  die  information  contained 
in  die  component  library  about  Ethernets,  as  well  as  tlte  infomiation  about 
bus  networks  and  networks  in  general. 


57 


Type  of  Network: 
Baseband 
Broadband 

Channel  Type: 

Coaxial  cable 
Twisted  pair 
Radio 

Fiber  optic 

Number  or  Stations: 
Maximum  of  1024 

Data  Rate: 
i  Mbps 
5  Mbps 
10  Mbps 
20  Mbps 


PACKET  SIZE: 

Must  be  between  56  and  1518  bytes 

Total  length  or  cable: 

Max  2500  meters 

Length  of  individual  cable  segments: 

Max  500  meters 

Number  OFCONNECTED  CABLE  SEGMENTS: 

Max  5 

Medium  attachment  Units  per  Segment: 
Max  100  per  Indiv.  cable  segment 

LENGTH  OF  MEDIUM  TRANSCEIVER  CABLE: 

Max  50  meters 


Figure  8b.  CSMA/CD  architecture  network 
(Carrier  Sense,  Multiple  Access  with  Collision  Detection 
as  defined  in  IEEE  Standaid  802.3). 


Type  or  Nei  work: 
Baseband 


PACKET  SIZE: 

Must  be  balwoun  64  and  1518  by  to  a 


Channel  type: 

Coaxial  cable 


Total  length  of  cable: 
Max  2500  meters 


Access  Methoo: 
CSMA/CD 


LENGTH  OF  INDIVIDUAL  CABLE  SEGMENTS: 
Max  500  meters 


Number  of  stations: 

Maximum  ol  1024 


Number  of  cowected  cable  segments: 
Max  5 


DATA  RATE: 

10  Mbps 

Backoff  algorithm: 

Binary  exponential  backoff 

INTEPPACKET  SPACING: 

0.6  pa 


Medium  Attachment  unit:;  per  Segment: 
Max  100  per  Indiv.  cable  segment 

length  or  Medium  Transceiver  Cable  . 
Max  50  muturs 

Distance  between  2  farthest  end  nodes: 
Max  2700  matvrs 


Figure  8c.  Ethernet  object  entiy, 

into  user  were  to  then  construct  an  information  llow  model  showing 
the  transmission  of  assets  sensitive  lo  disclosure  (confidentiality 
requirement)  along  this  network,  die  expert  system  would  lx.‘  able  to  infer  a 
possible  threat  lo  confidentiality  al  this  component,  based  on  its  knowledge 
of  die  vulnerability  of  coaxial  cable  bus  networks  to  undetected 
wiretapping.  U  might  then  propose  a  countermeasure,  .such  as  the 
installation  of  filler  optic  cable.  The  expert  system  would  also  know  that  a 
threat  agent  could,  via  a  single  eomjxinciU.  gain  access  to  the  assets  that 
are  processed  on  Hie  other  components  on  that  network,  and  consider  this 
possibility  in  relation  to  the  security  requirements  of  the  assets. 

Stalus  mid  Plum 

Our  system  lias  been  under  design  since  February  1987.  The  initial 
cnnccptunl  design  was  completed  in  mid- 1987  and  reviewed  internally  arid 
by  a  government  team  consisting  of  experts  from  the  National  Bureau  of 
Standards  and  the  National  Computer  Security  Center.  A  static  mockup  of 
a  sample  walkthrough  was  constructed  as  part  of  the  ptescutation.  In  early 
1988,  we  implemented  a  portion  of  the  system  for  proof  of  concept  on  a 
personal  computer.  Following  the  review  of  titis  implementation,  we  ate 
continuing  to  develop  an  initial  prototype  of  the  full-scale  system. 

Our  work  dius  far  has  revealed  a  number  of  areas  dial  need  more 
attention.  It  is  clear  that  a  lucid,  comprehensive,  workable  model  of  risk 
management  must  lie  formulated  as  the  basis  for  this  work.  We  are 
interacting  vigorously  with  major  government  and  industry  figures  in  this 


area  |4).  In  addition,  taxonomies  of  the  various  components  of  such  a 
model  must  lie  developed.  Il  is  especially  important  to  create  better 
quantitative  and  qualitalive  mcdiods  for  measuring  risk  and  analyzing 
trade-offs,  and  we  intend  to  investigate  the  use  of  reasoning  methods  from 
artificial  intelligence  and  traditional  sources  for  this  purpose.  For  example, 
estimates  of  tlic  likelihood  of  a  given  threat  action  occurring  arc  often 
necessarily  imprecise.  Fuzzy  set  theory  provides  tools  developed 
specifically  for  reasoning  with  imprecise  information,  and  can  be  utilized  in 
this  ease.  We  also  must  design  easy-to-use  and  reprcsentationally  adequate 
u  ter  presentation  and  interface  methods.  We  plan  to  putsuc  all  of  these 
issues  in  1988  and  1989. 
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Abstract 

Distributed  secure  systems  also  have  distrib¬ 
uted  security  policy  and  unequal  security 
risk.  The  n-squared  problem  (addressing 
security  interface  of  n  communicating  nodes, 
not  just  the  directly  connected  ones)  and  the 
cascading  problem  (creating  greater  risk  by 
connecting  systems  of  differing  data  exposure 
levels)  are  primary  sources  of  difficulty  in 
distributed  system  risk  analysis.  Landwehr 
and  Lubbes  described  factors  for  determining 
Orange  Book  evaluation  criteria  in  complex 
systems.  This  paper  expands  on  their  approach 
by  adding  network  risk  propagation  rules.  The 
modal  presented  here  is  applicable  to  evalua¬ 
tion  of  sensitivity  requirements  (preventing 
unauthorized  disclosure)  and  criticality 
requirements  (preserving  system  integrity  and 
availability)  in  heterogeneous  networks.  An 
automated  analysis  tool  has  been  developed. 


Background 

The  authors  discussed  issues  of  network  and 
distributed  system  security  at  last  year's 
conference  (1).  There  the  ideas  of  Biba  [2] 
and  others  were  used  to  propose  a  criticality 
approach  similar  to  that  used  when  protecting 
sensitive  information,  which  is  the  primary 
objective  of  current  security  policy  and 
requirements  (see  Figure  1).  Aloe  discussed 
were  techniques  of  system  decomposition,  an 
approach  which  deals  individually  and  in 
combination  with  the  elements  of  vary  large 
systems. 


^Ss*sKsC|‘IUrla 

Topic 

Sensitivity 
(F.xUtlng  BatU) 

Criticality 

(Proposed  Enhancement!) 

Protect 

CImi tiled  date 

Million  Data 

Control  Data.  Proceuei 

Threat 

Diicloiure 

Lou  of  Integrity 

Denial  of  Service 

Lovell 

Unclaulflod 

Confidential 

Secret 

Top  Secret 
(Compartmonti) 

Noncrltlcal 

Critical 

Highly -Critical 
(Compartment! 
potiible) 

Control  Goal 

Need-to-Know 

N  eed- to- Modify  /Ex  acuta 

Protection 

Mechanlema 

RuliUnce 

Refinance 

Detaction/Recovery 

Figure  1.  Network  Security  Elements 


This  paper  addresses  the  complex  subject  of 
risk  analysis  in  a  distributed  system.  The 
approach  follows  the  lead  of  National 
Computer  Security  Center  (NCSC)  Yellow  Book 
[3]  guidance  for  assigning  Orange  Book  [4] 
division  and  class  and  it  also  extends  the 
ideas  of  Landwehr  and  Lubbes  [5]  to  distrib¬ 
uted,  heterogenous  environments.  The  recently 
available  Trusted  Network  Interpretation 
(TNI,  [6])  provides  some  guidance  for  eval¬ 
uating  and  accrediting  heterogenous  networks, 
but  TNI  emphasis  1b  on  "single  trusted 
systems,"  This  paper  thus  describes  a  method- 
olgy  for  determining  security  (sensitivity 
and  criticality)  requirements  in  complex 
networks. 

A  system  security  policy  must  cover  all  of 
what  is  internal,  plus  external  communica¬ 
tions  interfaces  (logical  as  well  as 
physical).  This  follows  from  and  expands  the 
Orange  Book  concept  of  the  primary  external 
interface  as  the  human  "user."  The  concept 
covers  all  "external  subjects,"  including 
humans,  computers  (a.g,,  hosts),  networks, 
other  components  or  other  systems. 


The  identification/authentication  policy  must 
cover  each  of  these  external  subjects  and, 
using  access  control  capabilities,  determine 
what  controlled  information  can  be  received 
from  and  sent  to  each  of  them.  There  must  be 
label  consistency  or  a  mapping  technique  must 
be  defined  that  ensures  proper  protection  and 
integrity.  In  soma  systems  it  will  be  neces¬ 
sary  to  maintain  accountability  to  the  user 
level,  even  though  the  user  interface  is  with 
an  external  system.  Sometimes  the  policy 
will  require  accountability  only  at  the 
interfacing  system  level.  The  interface 
policy  deals  not  only  with  the  physical 
interoonnaotivi'ty,  but  also  with  all  pairs  of 
communicating  entities.  This  is  the  so 
called  N-squared  problem  (Figure  2). 
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Figure  2.  N -Squared  Problem 


Sometimes  data  are  passed  from  one  external 
system  through  the  system  of  interest  to 
another  external  system  (Figure  3).  Policy 
must  ensure  that  required  protection  consis¬ 
tent  with  a  mutual  interconnection  policy 
exists  at  the  interface.  If  the  systems  are 
nodes  of  a  network  that  receives  and  delivers 
encryptod  data  and  if  a  mandatory  sensitivity 
or  criticality  level  separation  or  a  discre¬ 
tionary  "need-to-know"  or  "need-to-modif y" 
exists,  the  appropriate  security  labels  and 
access  control  lists  must  be  shared  between 
the  two  systems  communicating  data.  The 
network  need  not  necessarily  be  aware  of 
these  labels  and  lists. 

Each  network  component  has  a  unique  security 
policy  (even  if  it  is  no  policy).  This 
policy  may  be  more  strict  or  less  strict  than 
the  policy  of  the  other  components. 
Inclusion  into  the  system  might  increase  the 
risk  associated  with  a  component  due  to  the 
cascading  problem  (Figure  4),  wherein  the 
range  of  security  levels  in  the  network  may 
be  greater  than  the  accreditation  range  of 
any  component. 


When  we  consider  the  security  policy  from  an 
overall  system  level,  it  must  be  assured  that 
all  component  policies  are  supported  through¬ 
out  the  system  (including  both  physical  and 
logical  interface).  Further,  there  may  be 
policy  dictated  at  the  system  level  that  is 
over  and  above  the  policy  that  exists  at  the 
individual  component  level,  and  this  higher 
level  policy  must  also  be  supported. 
Finally,  there  is  policy  at  the  system  level 
which  concerns  the  system's  interface  with 
the  outside  world,  and  it  must  be  ensured 
that  this  system  level  policy  is  supported  by 
the  components  that  interface  with  the  out¬ 
side  world  (external  subjects  to  the  system). 

Security  Risk 

The  goal  of  a  security  program  is  to  prevent 
the  disclosure  of  sensitive  information  to 
unauthorized  sources  and  to  protect  the 
integrity  and  availability  of  the  systems  and 
the  data  critical  to  mission  operations. 
This  goal  is  accomplished  through  the  process 
of  risk  management.  Risk  management  attempts 
to: 

o  Identify,  control,  and  minimize  the 
occurrence  and  effect  of  uncertain  events 
that  would  compromise  the  security  goals 

o  Obtain  and  maintain  the  authority 
for  approval  of  operations  involving  sensi¬ 
tive  or  critical  data  and/or  functions 
through  a  Designated  Approval  Authority  (DAA) 

o  Facilitate  information  system 
management  throughout  the  system’s  life  cycle 
based  on  security  requirements  and  protection 
levels. 


tiuois 


Figure  3.  interconnection  Policy 


Figure  4.  Cascading  Problem 


Risk  Modeling  is  a  method  of  correctly  deter¬ 
mining  evaluation  criteria  for  specification, 
design/development,  and  accreditation  pur¬ 
poses.  This  paper  presents  an  approach  which 
extends  Yellow  Book  and  Landwehr-Lubbes 
methods  to  complex  networks. 


X§ii2w„§22]S_l32i'!®.iA222  “  The  National 

Compute r~Secur!ty  Center  developed  the  orange 
Book  to  identify  protection  requirements 
associated  with  a  gradation  of  risk  levels. 
To  assist  in  the  assessment  of  risk  level  the 
NCSC  also  provided  the  Yellow  Book  guidance 
(CSC-STD-003-35,  illustrated  in  Figure  5). 
The  Yellow  Book  considers  these  parameters: 
the  maximum  sensitivity  of  the  data  to  be 
protected  by  the  system;  the  user  with  the 
minimum  clearance  level  who  potentially  has 
access  to  the  system;  and  whether  or  not  the 
system  was  developed  in  an  open  or  closed 
environment.  A  closed  environment  exists 
where  there  is  adequately  secure  design  and 
development  with  proper  configuration  control 
and  assurance.  Yellow  Book  risk  indices 
(exposure  levels)  are  summarized  in  Table  1. 

The  Yellow  Book  guidelines  also  make  recom¬ 
mendations  on  security  mode  of  operation 
based  on  the  degree  of  exposure  (maximum  data 
sensitivity  level  minus  minimum  user 
clearance  level).  Data  exposure  in  a 
dedicated  mode  or  system  high  environment  is 
by  definition  zero,  and  in  controlled  or 
multi-level  environments  the  potential 
exposure  is  equal  to  the  separation  between 
the  high  and  low  levels  being  protected. 
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Maximum  Data  Sensitivity 

Minimum 
User  Clearance 


Mode 


<^_Data  Exposure^} 


l  igure  5.  Yellow  Book  Approach 


Table  1.  Exposure  Levels 
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Landwehr  -  I.ubbes  Approach  -  Ir  order  to  try 
to  loosen  the  strict  guidance  of  the  Yellow 
Book  and  to  consider  other  variables,  the 
I.andwehr-Lubo: -»  approach  uses  the  fact  that 
different  users  possess  different  capabili- 
ties,  thereby  potentially  reducing  the 
identified  risk  and  criteria  levels.  In 
addition  to  the  data  exposure  parameters  of 
the  Yellow  Book,  this  approach  considers  the 
user  capability,  nature  of  the  communications 
path  and  local  processing  capability.  Thus, 
users  may  be  categorized  by  risk  levels. 
Expanding  on  the  previous  figure,  Figure  6 
shows  the  addition  of  the  Landwehr  -  Lubbes 
criteria  which  combines  system  risk  with  data 
exposure  to  determine  criteria  levels.  The 
matrices  for  determining  process  coupling 
risk  and  system  external  risk  are  shown  in 
Tables  2  and  3.  Table  4  shows  how  to  use  data 
exposure  and  system  external  risk  levels  to 
arrive  at  an  Orange  Book  evaluation  criteria 
division  and  class  for  sensitivity. 


Tabic  2.  Process  Coupling  Risk 
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Table  3.  System  External  Risk 


Ukt  Capability 

1’ioctss  CiMiplinj*  Riilt 
(I'Him  Table  2) 

-2 

-1 

4 

5 

6 

l.  Output-only  (Subscribed 

i 

4 

5 

4 

7 

2  Transaction  IWcuing 
{Analyst) 

5 

4 

7 

K 

l  ull  Driifciummuig 

6 

7 

K 

V 

Table  4.  Orange  Book  Levels 
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Table  5.  Mapping  System  KWk  using  f’rUUjUty  Division 
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Security  Risk  in  Networks.  Data  exposure  and 
the  Landwehr-Lubbes  criteria  appear  to  be 
equally  applicable  to  criticality.  Table  5 
can  be  used  to  determine  the  appropriate 
division  (A,  B  or  C)  of  criticality  criteria. 
Prototype  evaluation  criteria  for  criticality 
divisions  are  described  in  [7].  Factors  for 
applying  the  risk  methodology  to  criticality 
as  veil  as  to  sensitivity  are  described 
below.  The  method  presented  here,  including 
rules  that  utilize  the  Landwehr-Lubbes 
matrices,  accounts  for  the  propagation  of 
risk  in  networks. 

Network  cor  catenation/Propagatlon  Rules  -  It 
was  an "objective  to  follow  the  principles  of 
the  Yellow  Book  and  it  also  seemed  that  the 
essence  of  risk  in  the  distributed  system 
problem  was  embodied  in  the  capabilities 
possessed  by  the  remote  users.  Before  these 
rules  could  be  applied  it  was  first  obvious 
that  the  cascading  effect  of  both  maximum 
data  sensitivity  and  minimum  user  clearance 
would  have  to  be  dealt  with.  Further,  the 
communication  of  a  user  with  a  remote 
computer  system  might  not  be  only  through  a 
variety  of  communications  links,  but  also 
through  systems  that  may  or  may  not  be 
trusted  and  may  or  may  not  take  responsibil¬ 
ity  for  tne  data  and  its  communication. 

The  approach  taken  (Figure  7)  was  to  identify 
concatenation  and  propagation  rules  that 
applied  to  the  maximum  data  level  being 
protected  (e.g.,  through  the  cascading 
effect),  to  the  minimum  user  clearance  level 
protected  against,  and  finally  to  the  inter¬ 
pretation  of  multiple  (and  remote)  communica¬ 
tions  paths.  The  rules  adopted  for  maximum 
data  sensitivity  and  minimum  user  clearance 
are  given  in  Figure  8.  If  we  are  evaluating 
System  A  with  respect  to  system  B,  then 
system  A  assumes  the  maximum  data  sensitivity 
level  equal  to  the  maximum  of  A  and  B  if 
there  are  no  trusted  absorbing  nodes  or  if 
there  are  no  one-way  data  lines  that  only 
carry  data  in  the  direction  from  A  to  3. 


A  "trusted  absorbing  node"  is  a  node  that  has 
a  trusted  system  base  at  the  appropriate 
level,  takes  and  controls  information  that 
comes  into  it  via  security  policy  that 
considers  trust  levels  of  the  systems  with 
which  it  interfaces  and  controls  communica¬ 
tions  with  the  destination.  A  node  is  not 


Figure  7.  Network  Evaluation  Approach 


trusted  absorbing  either  if  it  is  not  trusted 
or  if  it  is  trusted  but  merely  acts  as  a 
store  and  forward  switch  in  the  communica¬ 
tions  system,  taking  no  responsibility  for 
the  labels  or  the  policy  associated  with  the 
communications . 

Propagation  of  minimum  user  clearance  is 
defined  similarly?  however,  note  that  the 
direction  of  the  one-way  rule  is  reversed. 
Both  of  these  rules  apply  to  criticality  as 
well  as  sensitivity,  with  the  exception  that 
the  directions  of  the  one-way  rules  are  re¬ 
versed  in  both  cases.  In  criticality  we  are 
worried  about  writing  and  activating,  and 
less  worried  about  data  exposure. 

To  enhance  the  Landwehr-Lubbes  criteria,  we 
further  expand  the  criteria  used  to  interpret 
a  complex  path  to  determine  the  matrix  value 
for  "communications  path"  to  use  in  the 
process  coupling  risk  matrix  (previously 
given  in  Table  2).  These  additional  criteria 
are  given  in  Figure  9,  where  trusted 
absorbing  node  and  one-way  are  defined  as 
before.  Two-way  is  defined  as  in  the 
original  Landwehr-Lubbes  paper,  where  there 
is  a  two-way  store-and-forward  capability, 
but  no  direct  interaction. 


Figure  8.  Network  Propagation  Rules 


Rule  3:  1 

To  determine  comm,  oath  for  Table  2  i 

If  one-way  in  direction  of  A,  or 

trusted  absorb,  node  in  path  - 

No  path 

If  one-way  away  from  A 

-  1 

If  two-way 

-  2 

Otherwise  (e.g.,  LAN) 

-  3 

Figure  9.  Network  Propagation  Rules  (corn.) 


I - 

i  Rule  1;  Mtaimuni  Ditla^eiiaimia 

(Evaluate  A  with  respect  B) 

If  trusted  absorbing  nodes  in  path,  or 
one-ways  away  from  A.  then 
Am  ax  =  Am  ax. 

Otherwise  Atttax  -  Max(Ainax.Bmax) 

Rule  2:  Minimum  lisoCkatanca 

(Evaluate  A  with  respect  to  B) 

if  trusted  absorbing  nodes  in  path,  or 
one-ways  in  the  direction  of  A,  then 
Amin  »  Amin. 

Otherwise  Amin  =  Min(Amin.Bmin) 

(For  criticality  the  one-way  rules  are  reversed) 
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Risk  Evaluation  Model  and  Examples  -  The  de¬ 
termination  of evaluation  criteria  in  net¬ 
worked  systems  can  now  be  accomplished  by 
applying  the  concatenation  and  propagation 
rules,  and  then  performing  the  evaluation 
implied  by  the  original  approaches  of  the 
Yellow  Book  and/or  Landwehr-Lubbes  criteria. 

The  problem  is  not  a  simple  one  as  can  be 
seen  from  the  simple  network  example.  in 
theory,  every  path  from  each  source  to  each 
destination  element  must  be  considered  in 
this  evaluation,  or  must  at  least  go  as  far 
as  is  required  to  show  that  there  will  be  no 
cascading  of  security  properties.  Develop¬ 
ment  of  the  algorithm  into  an  automated 
software  tool  is  in  progress.  This  tool 
facilitates  the  engineering  process,  since 
all  but  the  simplest  of  analyses  become  too 
complex  to  deal  with  manually,  as  will  be 
illustrated. 

Any  model  must  have  implicit  and  explicit 
simplifying  assumptions.  In  our  model,  the 
entire  threat  is  through  system  users  who 
have  limited  access.  it  is  assumed  that 
computers  are  physically  protected  and  that 
communications  liner,  are  either  physically 
protected  or  the  data  are  protected  with 
encryption  and  integrity  encoding.  It  is 
also  assumed  that  interface  policies  have 
been  devised  and  that  these  policies  can  be 
enforced  by  trusted  systems.  As  an  example, 
if  a  trusted  system  receives  data  from  an 
untrusted  system,  it  will  not  trust  the 
labels  and  will  treat  those  data  at  system 
high  level  of  the  untrusted  system. 

The  definitions  of  nodes,  systems,  and 
terminals  are  left  to  the  judgement  of  the 
evaluator  and  ultimately  the  DAA.  Full 
capability  high  performance  microprocessors 
might  be  treated  as  systems.  The  definition 
also  might  differ  depending  on  whether  a 
sensitivity  or  a  criticality  analysis  is 
being  made.  For  example,  a  network  node  may 
be  performing  routing  and  other  processing 
based  on  protocol  information,  and  labels. 
Other  simplifications  will  be  apparent  as  we 
go  through  an  example. 


The  procedure  for  evaluating  risk  (i.e., 
determining  protection  levels)  in  hetero¬ 
genous  networks  is  summarised  as  follows. 
Consider  the  risk  evaluation  of  System  A  in  a 
network  (see  Figure  10).  For  each  potential 
path  to  system  A  from  each  external  subject: 


-  Determine  max.  data  sensitivity 

-  Determine  min.  user  clearance 

-  Determine  path  data  exposure 

-  Dete:rraine  communication  path 

-  Determine  process  coupling  risk 

-  Determine  system  external  risk 

-  Map  system  risk  and  data 
exposure  to  Orange  Book  level 


(rule  1) 
(rule  2) 
(table  1) 
(rule  3) 
(table  2) 
(table  3) 

(table  4) 


This  yields  criteria  level  for  that  path. 
Security  requirements  and  associated  protec¬ 
tion  mechanisms  for  each  path  must  be 
analyzed  and  validated.  System  A  risk  level 
becomes  the  worst  case  path.  Thu  analysis  is 
repeated  for  System  A  criticality  threat. 
Finally,  the  process  is  repeated  for  all 
systems  in  the  network. 


As  an  example,  consider  a  very  small  part  of 
the  system  in  Figure  10,  consisting  only  of 
systems  A,  B,  and  C  as  well  as  the  user 
terminal  connected  at  B.  Here  we  are 
performing  the  evaluation  only  with  respect 
to  A.  This  evaluation  example  is  shown  in 
Figure  11.  We  are  performing  only  a 
sensitivity  evaluation;  however,  a  critical¬ 
ity  evaluation  would  follow  similarly,  but 
using  the  slightly  altered  concatenation/pro¬ 
pagation  rules  and  different  risk  matrices. 


Figure  10.  Evaluation  of  System  A  in  a  Network 


The  elements  are  given  starting  states  and 
from  these  it  is  determined  how  risk  is  pro¬ 
pagated  into  A.  The  user  at  B  has  a  Confi¬ 
dential  clearance,  systems  B,  A,  and  C 
respectively  have  Confidential,  Secret,  and 
Secret  minimum  user  clearance  levels.  They 
also  possess,  respectively.  Secret,  Secret 
and  Top  Secret,  maximum  data  sensitivity. 
Neither  A,  B,  or  C  are  trusted  absorbing 
nodes.  Programming  can  be  accomplished  at 
the  terminal  and,  once  a  user  logs  on, 
programming  could  be  done  at  any  of  systems 
A,  B,  and  C.  Two-way  (store  and  forward) 
links  exist  between  the  terminal  and  system  B 
and  between  systems  B  and  C.  A  one-way  link 
connects  system  A  and  B  where  data  can  travel 
from  A  to  B,  but  not  in  the  other  directicjn. 
Another  one-way  data  link  allows  flow  of  data 
from  C  to  A,  but  not  in  the  other  direction. 

Evaluating  the  results  shows  a  path  from  the 
terminal  to  B  to  A,  but  it  is  one-way  and 
rates  a  1  in  the  Landwehr-Lubbes  criteria. 
The  path  through  B  and  then  C  is  not 
considered  a  path  because  of  the  one-way  in 
the  wrong  direction.  (Note  that  Landwehr- 
Lubbes  is  worried  about  leakage  of  sensitive 
information  but  is  not  concerned  with  the 
user  being  able  to  send  data  into  A,  which  is 
a  criticality  problem.)  The  minimum  user 
clearance  in  A  must  be  updated  to  Confiden¬ 
tial  since  data  from  A  is  now  exposed  to  that 
level.  Further,  the  maximum  data  sensitivity 
of  A  must  be  updated  to  Top  Secret  since 
there  is  a  potential  leakage  path  from  C  to 
A. 


Now  we  are  able  to  assess  the  risk  level  at 
System  A  (only)  based  on  the  information 
given  in  this  simple  example,  and  from  that 
determine  the  applicable  Orange  Book  level. 
Using  Table  2,  the  process  coupling  risk  is 
determined  to  be  a  4.  Further,  the  system 
external  risk  is  determined  to  be  a  7  from 
Table  3.  The  data  exposure  between  Confiden¬ 
tial  user  and  Top  Secret  data  from  Table  1  is 
determined  to  be  3.  Bused  on  this  exposure, 
the  Yellow  Book  would  recommended  a  B3  class 
(as  with  Landwehr-Lubbes,  open  environments 
are  assumed).  From  Table  4,  the  Landwehr- 
Lubbes  approach  (with  network  propagation 
effects  factored  in)  recommends  a  B2/B3  level 
of  criteria. 
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Evaluate  System  A  with  respect  to  B  &  C 
(Potential  pallts  are  BA  and  BCA). 


Initial  Parameters 

User  at  B 

System  B 

System  C  ] 

System  A 

Min  User  Clearance 

C 

c 

S 

S 

Max  Data  Sensitivity 

s 

TS 

S 

Trusted  Absorption 

No 

No 

No 

Local  Process  Capab. 
User  Capability 

P 

P 

P 

P 

Risk  Calculation  for  Palli  BA  (BCA  is  not  a  valid  path  in  this  case). 

Max  Data  Sensitivity  (rule  1):  max  (A.B.C) =  TS 
Min  User  Clearance  (rule  2):  min(A,B)  =  C 
Path  Data  Exposure  (table  I ):  (5,2)  =  3 
Comm  Path  (rule  3):  1 

Process  Coupl.  Risk  (table  2):  (3.1  )  =  4 
System  Ext.  Risk  (table  3):  (3,4)  =  7 
Orange  Book  Level  (table  4):  (3,7)  =  B2/B3 
(Yellow  Book  =>  B3) 


Figure  1 1.  Risk  Evaluation  Example  (1) 


Evaluate  System  A  with  respect  to  B  &  C 
(Potential  paths  arc  BA  and  BCA). 
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Initial  Parameters 

User  at  B 

System  B 

System  C 

System  A 

Min  User  Clearance 

C 

C 
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S 

Max  Data  Sensitivity 

c 

TS 
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Trusted  Absorption 

No 

No 

No 

Local  Process  Capab. 
User  Capability 

P 

P 

P 

P 

Risk  Calculation  for  Path  BA 
Max  Data  Sensitivity  (rule  1 ):  max  (A.B) »  S 
Min  User  Clearance  (rule  2):  min  (A,B)  =  C 
Path  Data  Exposure  (table  1):  (3.2)=  1 
Comm  Path  (rule  3):  3 

Process  Coupl.  Risk  (table  2):  (3.3)  =  6 
System  ExL  Risk  (table  3):  (3.6)  «■  9 
Orange  Book  Level  (table  4):  ( 1 ,9) »  B 1 
(Yellow  Bock  =>  HI) 


Max  (A.B.C)  =  TS 
Min  (A.B.C) «  C 

(5.2)  =•■  3 
3 

(3.3)  =  6 
(3,6)  .  9 
(3,9)  =  B3/A1 
(Yellow  Bool.  ->  R3) 


Figure  12.  Risk  Evaluation  Example  (2) 


We  purposely  went  through  this  first  example 
step  by  step,  relating  it  to  the  appropriate 
rules  and  tables.  If  we  were  to  evaluate  the 
network  in  Figure  10  just  with  respect  to 
system  A,  we  would  have  co  consider  each 
potential  path  from  each  user  and  from  each 
of  the  other  systems  to  system  A.  A  Local 
Area  Network  evaluation  example  is  presented 
in  Figure  12.  Studying  numerous  examples  and 
results  of  the  automated  evaluation  tool 
provides  insight  into  network  security 
problems.  One  revelation  is  that  the  security 
design  solution  with  respect  to  node  A  may  be 
not  changing  node  A  at  all.  The  solution  may 
be  to  insert  a  more  restrictive  communication 
link  on  the  other  side  of  the  network  to 
reduce  A's  exposure.  Although  this  is 
intuitively  obvious  for  simple  networks,  it 
is  less  obvious  in  complex  networks. 

Conclusions 

We  have  presented  a  deterministic  apnroach 
for  dealing  with  the  distribution  of  i  sk  in 
connected  systems.  The  methodology  is  more 
qualitative  than  quantitative,  since  many 
risk  factors  are  difficult  to  quantify 
precisely.  We  used  as  a  starting  point  the 
NCSC  Yellow  Book  guidance  and  the  Landwehr- 
Lubbes  approach.  The  evaluation  methodology 
described  here  enables  consistent  determina¬ 
tion  of  network  criticality  and  sensitivity 
evaluation  criteria  (i.e.,  requirements). 
This  approach  may  also  be  adapted  for  other 
than  DoD  environments,  where  a  hierarchical 
set  of  security  requirements  exists.  The  risk 
evaluation  methodology  described  here  has 
been  programmed  to  simulate  many  different 
system  environments. 
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Abstract 

Today’s  computer  systems  arc  vulnerable  to  both 
abuse  by  insiders  and  penetration  by  outsiders,  as 
evidenced  by  the  growing  number  of  incidents  re¬ 
ported  in  the  press.  Because  closing  all  security 
loopholes  from  today’s  systems  is  infeasible,  and 
since  no  combination  of  technologies  can  prevent  le¬ 
gitimate  users  from  abusing  their  authority  in  a  sys¬ 
tem,  auditing  is  viewed  as  the  last  line  of  defense. 

What  is  needed  are  automated  tools  to  analyze  the 
vast  amount  of  audit  data  for  suspicious  user  be¬ 
havior.  This  paper  presents  a  survey  of  the  auto¬ 
mated  audit  trail  analysis  techniques  and  intrusion- 
detection  systems  that  have  emerged  in  the  past  sev¬ 
eral  years. 

1  Introduction 

The  last  few  years  have  seen  a  sudden  and  growing  inter¬ 
est  in  automated  security  analysis  of  computer  system  au¬ 
dit  trails  and  in  systems  for  real-time  intrusion  detection. 
There  is  a  growing  number  of  research  activities  devoted  to 
the  subject,  and  some  operational  systems  and  oven  a  few 
commercial  products  have  appeared. 

The  earliest  work  on  the  subject  was  a  study  by  Jim 
Anderson  [  1  ],  who  categorized  the  threats  that  couid  be 
addressed  by  audit  trail  analysis  as 

•  Kxtornal  ponelrators  (who  are  not  authorized  to  use 
the  computer) 

•  Internal  penolrators  (who  are  authorized  to  use  the 
computer  but  not  the  data,  program,  or  resource,  ac¬ 
cessed),  including 

Masqueraders  (who  operate  under  another  user’s 
id  and  password) 

-  Clandestine  users  (who  evade  auditing  and  ac¬ 
cess  controls) 

•  Misfeasors  (who  are  authorized  to  use  the  computer 
arid  resources  accessed  but  misuse  their  privileges) 

Anderson  suggested  that  external  penetrators  could  be 
detected  by  auditing  failed  login  attempts  and  ttiat  some 
wouid-be  internal  penetrators  couid  be  detected  fry  observ¬ 
ing  failed  access  attempts  to  files,  programs,  and  other  re¬ 
sources.  He  suggested  that  masqueraders  could  be  detected 
by  observing  departures  from  established  patterns  of  use  for 
individual  users.  All  of  these  approaches  have  been  adopted 
in  subsequent  studies. 

Anderson  offered  no  suggestions  for  detecting  legitimate 
users  who  abuse  their  privileges.  To  detect  sucli  abuse  how¬ 
ever,  a  priori  rules  for  acceptable  behavior  could  be  estab¬ 
lished;  this  approach  has  been  taken  in  a  few  studies.  Com¬ 
parison  with  t.he  norm  established  for  the  class  of  user  to 


which  the  user  belongs  also  could  detect  abuse  of  privilege; 
this  approach  is  under  consideration  by  the  research  group 
at  SRI. 

The  clandestine  user  can  evade  auditing  by  using  system 
privilege  or  by  operating  at  a  level  below  which  auditing  oc¬ 
curs.  The  former  might  be  detected  by  auditing  all  use  of 
functions  that  turn  off  or  suspend  auditing,  change  the  spe¬ 
cific  users  being  audited,  or  change  other  auditing  param¬ 
eters.  The  latter  might  be  addressed  by  low-level  auditing, 
sucii  as  auditing  system  service  or  kernel  calls.  Anderson 
suggested  monitoring  certain  system-wide  parameters,  such 
as  CPU,  memory,  and  disk  activity,  and  comparing  these 
with  what  has  been  historically  established  as  usual  or  nor¬ 
mal  for  that  facility.  At  least  one  subsequent  study  has 
included  this  approach  (2). 

2  The  Experiments 

Subsequent  to  Anderson’s  study,  early  work  focused  on  de¬ 
veloping  procedures  and  algorithms  for  automating  the  of¬ 
fline  security  analysis  of  audit  trails.  The  aim  of  such  algo¬ 
rithms  and  procedures  was  to  provide  automated  tools  to 
help  the  security  administrator  in  his  or  her  daily  assess¬ 
ment  of  the  previous  day’s  computer  system  activity  [3,4], 
One  sucli  project  used  existing  audit  trails  and  studied  pos¬ 
sible  approaches  for  building  automated  tools  for  audit  trail 
security  analysis  |3|.  Another  such  project  considered  build¬ 
ing  special  security  audit  trails  and  studied  possible  ap¬ 
proaches  for  their  automated  analysis  [4].  These  projects 
provided  the  first  experimental  evidence  that  users  could 
be  distinguished  from  one  another  based  on  their  patterns 
of  use  or  the  computer  system  [3],  and  that  user  behavior 
characteristics  could  be  found  that  could  be  used  to  dis¬ 
criminate  between  normal  user  behavior  and  a  variety  of 
simulated  intrusions  [4]. 

2.1  The  Sytek  Work 

A  tool  Lhat  ranked  user  sessions  by  their  suspiciousness 
would  allow  the  system  security  officer  to  analyze  audit  trail 
records  that  are  most  likely  to  represent  intrusions  with¬ 
out  having  to  wade  through  volumes  of  records  of  mostly 
normal  user  activity,  The  Sytek  work  sought  to  provide  a 
feasibility  demonstration  for  such  a  tool  [Sj. 

Sytek 's  work  was  guided  by  concepts  from  pattern 
recognition  theory.  User  sessions  were  recognized  as  nor¬ 
mal  or  intrusive  based  on  patterns  formed  by  the  individual 
records  on  the  audit  trail  for  that  session.  The  Sytek  study 
defined  several  audit  record  features  as  functions  of  thn  au¬ 
dit  record  fields.  For  each  user,  expected  values  for  the 
features  were  determined  through  a  process  called  training 
(that  is,  for  each  feature,  the  set  or  range  of  values  was 
determined  from  the  audit  data).  The  study  then  tested 
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the  features  for  their  ability  to  discriminate  between  nor¬ 
mal  sessions  and  sessions  containing  staged  intrusions.  A 
session  was  flagged  as  intrusive  by  a  feature  if  the  value  of 
the  feature  calculated  for  the  session  was  outside  the  user’s 
range  or  set  of  expected  values.  Features  that  successfully 
detected  the  staged  intrusions  were  combined  to  create  a  for 
each  user  user  profile — the  collection  of  the  normal  ranges 
for  each  feature. 

Sytek  wrote  software  to  collect  audit  data  from  a  Unix1 
system  that  were  analogous  to  data  available  in  general- 
purpose  operating  systems.  An  audit  record  containing  the 
command  name,  associated  flies,  process  statistics,  and  file 
statistics  was  generated  whenever  a  user  issued  a  command. 

The  Sytek  team  collected  one  week  of  audit  data  and 
generated  a  set  of  statistics  to  identify  features  of  the  audit 
trail  that  were  potentially  useful  in  discriminating  among 
users  [6].  Each  identified  feature  was  trained  on  the  pre¬ 
sumedly  normal  audit  data  to  establish  a  range  or  set  of 
expected  values  exhibited  during  each  user’s  sessions.  The 
Sytek  team  then  enacted  and  audited  various  intrusion  sce¬ 
narios  in  such  a  way  that  the  intrusions  were  embedded 
into  tlie  audited  behavior  of  legitimate  users  of  the  sys¬ 
tem  [7|.  The  intrusion  scenarios  included  break-ins  by 
outsiders,  intruders  and  legitimate  users  masquerading  as 
other  users,  and  users  deliberately  subverting  the  system  in 
various  ways.  Sytek  then  tested  the  selected  features  to  see 
whether  they  were  useful  in  detecting  the  simulated  intru¬ 
sions  (8j.  Those  features  that  detected  one  or  more  of  the 
simulated  intrusions  were  retained  for  further  study. 

Sytek  then  tested  each  feature  still  under  considera¬ 
tion  against  an  additional  week  of  (presumedly  normal) 
audit  data  to  determine  the  percentage  of  normal  sessions 
the  feature  (lagged  as  abnormal  (i.e.,  the  false-alarm  rate). 
Sytek  found  that  the  features  password  changed,  user  iden¬ 
tity  queried,  and  access  to  system  dictionary  performed  ex¬ 
tremely  well.  It  found  the  most  effective  tile  statistics  were 
device  on  which  the  accessed  file  resides,  file  size,  oversized 
file  associated  with  this  command,  group  id  of  the  owner  of 
the  accessed  file,  and  user  id  of  the  owner  of  the  accessed 
file.  The  most  effective  process  statistics  were  time  of  use, 
day  of  use,  user  program  CPU  time,  and  maximum  total 
memory  use.  These  12  features  had  low  (under  15  percent) 
false-alarm  rates  and  were  selected  for  use  in  a  pattern  clas¬ 
sifier  that  analyzed  their  composite  performance  [9,10]. 

The  pattern  classifier  flagged  those  sessions  that  did  not 
fall  within  the  pattern  defined  by  the  user  profiles.  The 
idea  was  that  the  resultant  set  of  flagged  sessions  should  be 
sufficiently  small  to  enable  a  security  officer  to  examine  the 
set  manually. 

T.ie  performance  of  the  pattern  classifier  could  be  dif¬ 
ferent  from  that  of  the  individual  features  taken  separately, 
because  (l)  if  several  features  individually  each  flagged  a 
certain  session,  the  composite  would  flag  that  session  only 
once,  so  the  composite  could  flag  fewer  normal  sessions  and 
thus  have  better  performance  than  the  features  taken  indi¬ 
vidually  and  (2)  one  feature  might  not  flag  the  same  normal 
sessions  as  another  feature,  so  the  combination  of  features 
could  flag  more  normal  sessions  and  thus  have  worse  per¬ 
formance  than  the  features  taken  individually. 

Sytek  also  attempted  to  compute  a  certainty  measure 
that  would  indicate  the  degree  of  certainty  that  a  flagged 
session  actually  represented  an  intrusion  or  the  degree  or 
suspicion  for  a  user  session  They  computed  a  cerLainty  for 
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each  feature,  namely,  the.  number  of  audit  records  within  a 
session  that  were  flagged  by  the  feature.  They  then  com¬ 
puted  a  certainty  for  a  session  as  the  sum  of  the  certainties 
for  all  12  features. 

In  tests  to  analyze  for  intrusion-detection  strength  and 
false-alarm  rate,  the  pattern  classifier  successfully  detected 
all  the  simulated  intrusions.  However,  the  false-alarm  rate 
was  high  (between  40  and  70  percent).  Much  better  perfor¬ 
mance  could  be  expected  if  a  longer  training  period  were 
used. 

Four  of  the  selected  features  pertained  to  a  user’s  com¬ 
mand  usage  patterns.  These  features  were  very  good  at 
detecting  the  intrusion  scenarios  but  had  very  high  false- 
alarm  rates.  Believing  that  command  usage  patterns  were 
potentially  very  useful  in  discriminating  between  normal 
and  abnormal  behavior,  Sytek  decided  to  modify  these  fea¬ 
tures  to  improve  their  performance.  It  decided  to  make 
these  features  fuzzy,  that  is,  to  allow  the  computed  value 
for  a  user’s  session  to  be  a  certain  distance  from  the  range 
in  the  user’s  profile  before  the  session  was  flagged  as  abnor¬ 
mal.  The  greater  the  fuzziness,  however,  the  greater  the 
chance  of  missing  intrusions.  For  each  of  the  four  measures, 
Sytek  analyzed  the  effect  of  increasing  the  fuzziness  on 
both  the  intrusion-detection  strength  (percentage  of  scenar¬ 
ios  flagged)  and  on  false-alarm  rate  (percentage  of  normal 
sessions  flagged).  To  reach  an  acceptable  false-alarm  rate, 
the  intrusion-detection  strength  was  also  greatly  reduced. 
Sytek  found,  however,  that  for  features  proportional  real  du¬ 
ration  of  command  (percentage  of  a  session’s  real  elapsed 
time  spent  in  the  command)  and  proportional  CPU  dura¬ 
tion  of  command  (percent  of  a  session’s  CPU  time  spent  in 
the  command),  ail  acceptable  false-alarm  rate  was  achieved 
with  a  relatively  modest  reduction  in  intrusion-detection 
strength.  Hence,  these  two  features  showed  considerable 
promise  as  discriminators  of  intrusive  behavior. 

2.2  The  SRI  Study 

A  group  at  SRI  led  by  Hal  Javitz  performed  an  exten¬ 
sive  statistical  analysis  on  audit  data  from  IBM  systems 
running  MVS  and  VM.  The  purpose  of  the  study  was  to 
develop  analytical  statistical  techniques  for  screening  com¬ 
puter  system  accounting  data  to  delect  user  behavior  in¬ 
dicative  of  intrusions.  A  high-speed  algorithm  was  devel¬ 
oped  that  could  accurately  discriminate  among  users  based 
on  their  behavior  profiles. 

Audit  data  were  obtained  from  normal  system  account¬ 
ing  records  for  IBM  VM  and  MVS  systems.  Because  the 
overwhelming  majority  of  information  in  the  accounting 
records  concerned  system  usage  parameters  that  either  were 
beyond  the  control  of  the  user,  bore  no  reasonable  relation¬ 
ship  to  intrusion  attempts,  or  were  redundant  with  infor¬ 
mation  contained  on  other  accounting  records,  subset  of  the 
accounting  data  was  selected  that  could  be  used  to  detect 
logon  activity  outside  the  user's  normal  range,  execution 
lime  outside  the  user’s  normal  range,  activity  from  other 
than  a  user’s  normal  set  of  input  or  output  (I/O)  devices, 
and  files  for  which  the  user  is  authorized  but  which  are  only 
infrequently  accessed  by  the  user. 

From  VM  accounting  records  the  research  group  ob¬ 
tained  logon  time  and  day  of  week,  logon  mode  (normal 
or  autoiog),  terminal  used,  minidisks  accessed,  connect 
time,  computer  system  accessed,  CPU  time,  number  of  page 
reads  and  writes,  number  of  virtual  cards  read  and  punched, 


Lb 


and  number  of  virtual  lines  printed.  From  MVS  accounting 
records  they  obtained  time  and  day  of  week,  computer  sys¬ 
tem  used,  job  priority,  CPU  time,  number  of  job  steps,  I/O 
units,  card  reader  class  and  type,  number  of  card  images, 
number  of  programs  run,  number  of  files  accessed,  number 
of  changes  of  index  levels,  and  number  of  VSAM  records 
inserted,  retrieved,  updated,  or  deleted. 

They  created  a  database  containing  4  weeks  of  audit 
data  for  a  set  of  representative  users.  They  selected  a  job 
as  the  unit  of  analysis  for  batch  users  and  a  session  for 
interactive  users  (both  are  referred  to  as  jobs  hereinafter) 
and  characterized  each  job  by  variables  such  as  CPU  time 
used,  terminal  used,  and  the  number  of  files  accessed.  They 
then  used  these  variables  to  construct  a  profile,  representing 
the  statistical  norm  for  the  user’s  jobs,  for  each  user. 

The  SRI  researchers  developed  statistical  techniques  to 
detect  jobs  that  deviated  from  the  profiles  developed  for 
each  user's  jobs.  The  statistical  algorithms  aimed  to  maxi¬ 
mize  the  true  positive  rate  (percentage  of  intrusions  identi¬ 
fied  as  abnormal)  and  minimize  the  false  positive  rate  (per¬ 
centage  of  normal  use  identified  as  abnormal).  A  true  pos¬ 
itive  rate  of  100  percent  means  that  all  intrusions  are  de¬ 
tected.  The  detection  ratio  is  the  true  positive  rate  divided 
by  the  false  positive  rate,  The  more  variable  user  behavior 
is,  the  higher  the  false  positive  rate  will  be.  Although  the 
false  positive  rate  can  be  reduced  by  raising  the  threshold 
of  the  statistical  test  (so  that  fewer  events  are  considered 
abnormal),  this  also  lowers  the  true  positive  rate. 

They  compared  the  results  obtained  when  the  following 
criteria  were  used  to  define  an  abnormal  job: 

•  A  job  is  abnormal  if  the  value  of  one  of  its  parameters 
has  a  probability  of  occurring  of  less  than  10  percent 
for  that  user. 

•  A  user’s  job  is  abnormal  if  a  discriminant  analysis 
shows  that  the  probability  that  the  job  was  submitted 
by  another  user  is  greater  than  the  probability  that 
the  job  was  submitted  by  the  user  in  question. 

They  split  the  4  weeks  of  audit  data  into  two  sets:  the 
training  set  (the  first  2  weeks  of  data),  used  to  determine 
the  statistical  thresholds  for  the  test,  and  the  verification 
set  (second  2  weeks  of  data),  used  to  measure  the  test's 
performance. 

Because  all  activity  represented  in  the  sample  database 
was  assumed  to  be  normal,  there  were  no  examples  of  in¬ 
trusive  behavior.  Thus,  for  each  measure  the  researchers 
calculated  a  surrogate  true  positive  rate  (the  probability  of 
identifying  a  user's  job  as  abnormal  when  measured  against 
another  user’s  job  pioflle)  and  a  surrogate  false  positive  rate 
(the  probability  of  identifying  a  user's  own  job  as  abnor¬ 
mal).  These  are  the  true  and  false  positive  rates  discussed 
below. 

For  VM  sessions,  by  far  the  best  indicators  were  the 
type  of  login  and  the  terminal  used;  both  of  these  had  ex¬ 
tremely  low  false  positive  rates  (and  low  to  medium,  true 
positive  rates,  but  very  high  detection  ratios).  Minidisk  id 
had  an  extremely  high  true  positive  rate,  but  also  a  high 
false  positive  rate.  The  computer  system  used  had  a  fairly 
high  true  positive  rate  and  a  low  false  positive  rate,  with 
a  detection  ratio  of  seven.  Most  other  characteristics  had 
detection  ratios  of  between  one  and  two. 

Discriminant  analysis  was  superior  to  measures  of  job 
abnormality  based  on  extreme  values  of  job  parameters. 
In  the  discriminant  analysis,  the  researchers  used  a  user's 


training  set  to  estimate  the  multivariate  probability  distri¬ 
bution  (with  respect  to  parameters  such  as  CPU  time,  time 
of  day,  etc.)  of  normal  jobs  for  that  user.  They  assumed 
a  certain  multivariate  probability  distribution  for  intrusive 
jobs,  They  then  used  classical  statistical  paradigms  to  de¬ 
termine  a  rule  for  classifying  a  job  as  normal  or  abnormal. 
With  this  approach,  every  point  in  the  multivariate  space 
is  assigned  a  value  equal  to  the  ratio  of  the  height  of  the 
intrusive  job  probability  distribution  to  the  height  of  the 
normal  job  probability  distribution.  The  points  with  the 
largest  ratios  form  a  critical  region  in  which  the  probability 
of  normal  jobs  belonging  to  that  region  is  less  than  u  few 
percent.  Once  a  user’s  critical  region  has  been  determined, 
a  new  job  for  that  user  can  be  considered  abnormal  if  it 
falls  into  the  critical  region,  and  normal  otherwise. 

Because  audit  data  containing  intrusive  jobs  were  not 
available,  two  different  approaches  were  taken  to  determine 
a  hypothetical  multivariate  probability  distribution  for  in¬ 
trusive  jobs: 

•  Nonintrusive  profile  approach:  Assume  that  intrusive 
jobs  have  a  uniform  distribution 

•  Surrogate  intrusive  profile  approach:  Use  other  users’ 
jobs  to  develop  a  probability  distr'bution  for  intrusive 
jobs 

For  MVS  jobs,  discriminant  analysis  produced  a  true 
positive  rate  of  over  90  percent  and  a  false  positive  rate  of 
only  6  or  7  percent.  F  jr  VM  sessions,  although  the  single 
parameter  rules  had  by  far  the  lowest  false  positive  rates 
(averaging  less  than  1  pccent),  the  discriminant  analysis 
method  had  a  much  higher  true  positive  rate  (over  80  per¬ 
cent).  The  false  positive  rate  was  shown  to  increase  with 
the  number  of  days  since  the  profile  was  last  updated.  The 
SRI  group  estimated  that  with  dally  profile  updating  the 
results  would  be  even  better.  If  additional  security-relevant 
audit  data  were  used  in  the  analysis,  they  estimated  that  a 
discriminant  analysis  would  produce  a  true  positive  rate  of 
90  to  98  percent  and  a  false  positive  rate  of  1  to  3  percent. 
Thus,  these  statistical  procedures  are  potentially  capable  of 
reducing  the  audit  trail  by  a  factor  of  100  while  detecting 
approximately  95  percent  of  all  intrusions  (3).  The  security 
officer  would  still  have  to  determine  whether  the  statistical 
abnormalities  represent  actual  intrusions. 

3  The  Intrusion-Detection  Sys¬ 
tems 

The  early  evidence  of  the  Sytek  and  Javitz  studies  was  the 
basis  for  a  real-time  intrusion-detection  system,  that  is,  a 
system  that  can  continuously  monitor  user  behavior  and  de¬ 
tect  suspicious  behavior  as  it  occurs.  This  system,  known  as 
IDES  (Intrusion-Detectior  .Xpert  System),  is  based  on  the 
approach  that  intrusions,  whether  successful  or  attempted, 
can  be  detected  by  flagging  departures  from  historically  es¬ 
tablished  norms  of  behavior  for  individual  users  [12,13], 
Another  real-time  approach,  called  keystroke  dynamics , 
is  based  on  measurements  of  certain  characteristics,  such 
as  typing  speed,  of  a  user’s  keyboard  activity.  Keystroke 
dynamics  has  been  found  to  be  a  powerful  means  of  contin¬ 
uously  verifying  the  identity  of  the  user  doing  the  typing. 

For  systems  like  IDES,  different  intrusion-detec  cion 
msasures  may  be  appropriate  to  different  classes  of  user. 
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For  example,  for  users  whose  activity  is  almost  always  dur¬ 
ing  normal  business  hours,  an  appropriate  measure  might 
simply  track  whether  activity  is  during  normal  hours  or  off 
hours.  Other  users  might  frequently  login  in  the  evenings 
as  well,  yet  still  have  a  distinctive  pattern  of  use  (e.g.,  log¬ 
ging  in  between  7  and  9  p.in.  but  rarely  after  9  or  between  5 
and  9);  for  such  users,  an  intrusion-detection  measure  that 
tracks  for  each  hour  whether  the  user  is  likely  to  be  logged 
in  during  that  hour  would  be  more  appropriate.  For  still 
others  for  whom  “normal”  could  be  any  time  of  day,  a  time- 
of-use  intrusion-detection  measure  may  not  be  meaningful 
at  all. 

There  are  obvious  difficulties  with  attempting  to  detect 
intrusions  solely  on  the  basis  of  departures  from  observed 
norms  for  individual  users.  Although  some  users  may  have 
well-established  pal  terns  of  behavior —logging  on  and  off  at 
close  to  the  same  times  every  day  and  having  a  charactcris 
tic  level  and  type  of  activity— -others  may  have  erratic  work 
hours,  may  differ  radically  from  day  to  day  iu  the  amount 
and  type  of  their  activity,  and  may  use  the  computer  in 
several  different  locations  and  even  time  zones  (in  the  of¬ 
fice,  at  home,  and  on  travel).  For  the  latter  type  of  user, 
almost  anything  is  normal,  and  a  masquerader  might  easily 
go  undetected.  Thus,  the  ability  fo  discriminate  between  a 
user’s  normal  behavior  and  suspicious  behavior  depends  on 
how  widely  that  user's  behavior  fluctuates  and  on  the  user’s 
range  of  normal  behavior.  And  although  thin  approach 
might  be  successful  for  penctrators  and  masqueraders,  it 
may  not  have  the  same  success  with  legitimate  users  who 
abuse  their  privileges,  especially  if  such  abuse  is  normal  for 
those  liuersi.  Moreover,  the  approach  is  vulnerable  to  de¬ 
feat  by  an  insider  who  knows  that  his  or  her  behavior  is 
being  compared  with  his  or  her  previously  established  be¬ 
havior  pattern  and  who  slowly  varies  their  behavior  over 
time,  until  they  have  established  a  new  behavior  pattern 
within  which  they  can  safely  mount  an  attack.  Trend  anal¬ 
ysis  on  user  behavior  patterns,  that  is,  observing  how  last 
user  behavior  changes  over  time,  may  be  useful  in  detecting 
such  attacks. 

Because  the  task  of  discriminating  between  normal  and 
intrusive  behavior  is  so  difficult,  another  study  has  taken 
the  straightforward  approacli  of  automating  the  security 
officer’s  job.  Such  an  approach  lends  itseif  to  traditional 
expert  system  technology,  in  which  the  special  knowledge 
of  the  intrusion-detection  experts  (the  system  security  otli- 
cers)  is  codified  as  rules  used  to  analyze  the  audit  data  for 
suspicious  activity.  The  obvious  drawback  to  this  approacli 
is  that  the  security  officers,  in  practice,  have  only  limited 
expertise.  Thus,  while  automating  these  rules  frees  the  se¬ 
curity  officer  to  perform  further  analysis,  such  rules  cannot 
be  expected  to  be  comprehensive,  This  approach  would  be 
more  aptly  called  a  security  officer’s  assistant. 

Several  study  teams  arc  attempting  to  comprehensively 
characterize  intrusions  (e.g.,  MIDAS  (2|).  These  systems 
encode  information  about  known  system  vulnerabilities  and 
reported  attack  scenarios,  as  well  as  intuition  about  suspi¬ 
cious  behavior,  in  rule-based  systems.  The  rules  are  fixed 
in  that  they  do  not  depend  on  past  user  or  system  behav¬ 
ior.  (An  example  of  such  a  rule  might  be  that  more  than 
three  consecutive  unsuccessful  login  attempts  for  the  same 
user  id  within  5  minutes  is  a  penetration  attempt.)  Audit 
data  from  the  monitored  system  are  matched  against  these 
rules  to  determine  whether  the  behavior  is  suspicious.  A 
limitation  of  this  approach  is  that  it  looks  for  known  vul¬ 


nerabilities  and  attacks,  and  the  greatest  threat  may  be 
unknown  vulnerabilities  and  the  attacks  that  have  not  yet 
been  tried;  one  is  in  a  position  of  playing  catch-up  with  the 
intruders. 

Below  is  a  survey  of  these  various  intrusion-detection 

systems. 


3.1  A  Priori  Rules  for  Normal  Program 
Behavior 

Paul  Karger  has  suggested  what  he  calls  a  knowledge-based 
name  checker  to  compare  the  names  and  types  of  objects  re¬ 
quested  (for  reading,  writing,  creation,  or  destruction)  by 
a  program  with  the  names  and  types  of  objects  expected 
for  the  program  (llj.  He  posits  as  an  example  a  FOR¬ 
TRAN  compiler  containing  a  Trojan  horse  that  surrepti¬ 
tiously  modifies  a  user's  LOGIN.CMD  file  while  compiling 
the  user’s  program.  The  name  checker  expects  the  FOR¬ 
TRAN  compiler  to  require  read  access  to  a  file  witli  a  user- 
supplied  name  and  a  suifix  of  .FOR  and  to  create  new  files 
with  tile  same  name  but  suffixes  of  .OBJ  and  .LIS.  If  the 
compiler  attompts  to  create  or  to  write  to  a  file  named  LO¬ 
GIN.CMD,  the  name  checker  would  recognize  that  such  a 
file  is  unexpected  for  the  FORTRAN  compiler.  Other  rules, 
for  a  Unix  system  for  example,  could  check  whether  a  user 
program  asks  for  set-uid  privileges. 

Although  Karger  envisions  the  name  checker  being  used 
for  access  control  decisions,  it  could  ulso  be  used  as  a  rulo- 
bwsed  form  of  real-time  intrusion-detection.  lie  suggests 
obtaining  the  rules  for  the  behavior  expected  of  commands 
from  information  already  known  to  the  computer  Bystem; 
for  example,  iu  VAX/VMS  from  the  command  definition 
tables.  For  user  programs  and  batch  jobs,  the  ueer  would 
encode  the  rules  in  what  Karger  calls  a  special  directory  tree, 
which  would  enumerate  the  objects  on  which  the  program 
is  expected  to  operate. 

3.2  IDES 

SRI  International  is  developing  a  prototype  intrusion- 
detection  system  called  IDKS  (Intrusion-Detection  Expert 
System)  |12,13|.  The  goal  of  IDES  is  to  provide  a  system- 
independent  mechanism  for  real-time  detection  of  all  types 
of  security  violations,  whether  they'  are  initiated  by  out¬ 
siders  who  attempt  to  break  into  a  system  or  by  insiders 
who  attempt  to  misuse  the  privileges  of  their  accounts.  The 
IDES  approach  is  based  on  the  hypothesis  that  any  ex¬ 
ploitation  of  a  computer  system’s  vulnerabilities  entails  be¬ 
havior  that  deviates  from  previous  patterns  of  use  of  the 
system;  consequently,  intrusions  can  be  delected  by  ob¬ 
serving  abnormal  patterns  of  use.  The  IDES  prototype 
is  based  on  the  IDES  model  developed  by  Dorothy  Den¬ 
ning  [14,15],  This  model  is  independent  of  any  particular 
target  system,  application  environment,  system  vulnerabil¬ 
ity,  or  type  of  intrusion,  thereby  providing  a  framework  for 
a  general-purpose  intrusion-detection  system. 

The  IDES  prototype  is  an  independent  system  that  runs 
on  its  own  hardware  (a  Sun  Workstation2)  and  processes 
audit  data  received  in  real  time  from  a  target  system  [12,13|. 
The  user  activity  monitored  by  the  IDES  prototype  in¬ 
cludes  login,  logout,  program  execution,  directory  modifi¬ 
cation,  file  access,  system  call,  session  location  change,  and 
network  activity. 
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IDES  is  driven  by  the  arrival  of  audit  records,  each 
of  which  describes  behavior  relevant  to  possibly  several 
intrusion-detection  measures.  (A  measure  is  an  aspect  of 
user  behavior.)  There  are  two  kinds  of  measures:  discrete 
and  continuous.  A  discrete  measure  is  one  whose  domain  of 
values  is  a  finite,  unordered  set  (c.g.,  the  set  of  locations). 
Such  measures  are  generally  constant  for  a  particular  user 
session,  for  example  location  and  time  of  login.  A  continu¬ 
ous  measure  is  one  whose  value  is  a  number  or  count  that 
accumulates  over  a  user  session  (e.g.,  connect  time,  CPU 
time,  and  I/O  activity). 

To  determine  whether  user  behavior  as  reported  in  the 
audit  data  is  normal  with  respect  to  past  or  acceptable 
behavior,  IDES  includes  user  behavior  profiles  for  the  mea¬ 
sures.  (A  profile  is  a  description  of  the  expected  behavior  of 
a  user  with  respect  to  a  particular  measure.)  The  profiles 
are  periodically  updated  based  on  observed  user  behavior, 
and  the  profile  data  arc  aged  using  a  decay  factor  that  gives 
the  data  a  half-life  of  50  days.  Thus,  the  profile  reflects  a 
moving  time  window  of  behavior  for  each  user.  Anomalous 
behavior  is  user  behavior  that  deviates  from  the  expected 
behavior  for  some  measure  by  an  amount  indicated  in  the 
user  profile  for  that  measure.  Because  IDES  can  bo  con¬ 
figured  to  monitor  arbitrarily  detailed  user  behavior,  it  is 
potentially  capable  of  detecting  intrusions  (for  example,  by 
masqueraders)  that  cannot  bo  dotected  by  the  target  sys¬ 
tem's  access  controls. 

The  IDES  prototype  has  demonstrated  its  ability  to 
adaptively  learn  users’  behavior  patterns;  as  users  alter 
their  behavior,  the  thresholds  maintained  in  the  profiles 
change.  This  capability  makes  IDES  a  flexible  system:  it 
does  not  have  to  be  given  rules  determined  by  a  human  ex¬ 
pert  in  order  to  learn  what  constitutes  suspicious  behavior; 
rather,  IDES  derives  its  own  rules.  Thus,  IDES  is  poten¬ 
tially  sensitive  to  abnormalities  that  human  experts  may 
not  have  considered. 

The  IDES  prototype  currently  monitors  a  DEC-'20Gf> 
machine  at  SRI  running  a  locally  customized  version  of 
the  TOI’S-20  operating  system”.  SRI  modified  the  TOl’S- 
20  operating  system  to  collect  audit  data,  transform  the 
data  into  the  IDES  format,  encrypt  the  formatted  data, 
and  transmit  the  records  to  IDES  according  to  the  IDES 
protocol. 

IDES’s  flexible  system-independent  audit  record  format 
and  protocol  for  the  transmission  of  audit  records  make  it 
adaptable  to  different  host  systems  without  fundamental 
alteration  (although  the  particular  measures  and  param¬ 
eters  chosen  will  depend  on  the  system  and  users  being 
monitored).  SRI’s  plans  are  to  adapt  IDES  to  monitor  a 
network  of  Sun  workstations  and  to  monitor  a  large  IBM 
mainframe  system  running  MVS. 

Now  that  the  framework  has  been  established,  adding 
additional  intrusion-detection  measures  to  IDES  is  straight¬ 
forward.  In  ongoing  work,  SRI  is  implementing  a  greater 
variety  of  intrusion-detection  measures,  including  some 
“second  order”  measures  to  detect  behavior  trends,  thereby 
improving  the  intrusion-detection  capability  of  IDES.  In 
addition,  an  expert  system  and  rule-base  that  encodes  in¬ 
formation  about  hypothesized  intrusion  scenarios  and  sus¬ 
picious  behavior  is  being  added  to  IDES. 

The  IDES  intrusion-detection  processes  are  imple¬ 
mented  on  a  Sun  3/260,  and  the  IDES  security  administra- 
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tor  interface  is  implemented  on  a  Sun  3/604.  The  security 
administrator  interface  maintains  a  continuous  display  of 
various  indicators  of  user  behavior  on  the  monitored  sys¬ 
tems  and  allows  the  security  administrator  to  choose  from 
a  menu  of  built-in  queries  or  to  build  ad  hoc  queries  against 
the  audit  data  and  profiles. 

3.3  MIDAS 

SRI's  IDES  prototype  detects  intrusions  by  flagging  user 
behavior  that  deviates  from  that  user’s  past  behavior.  An¬ 
other  approach  is  to  develop  an  intrusion-detection  system 
that  encodes  a  priori  rules  that  define  an  intrusion.  This 
approach  is  used  in  the  Muitics  Intrusion  Detection  and 
Alerting  System  (MIDAS),  being  developed  by  the  National 
Computer  Security  Center  to  monitor  a  U.S.  government 
Muitics  system  (2|. 

MIDAS  is  implemented  on  a  stand-alone  Symbolics 
LISP  machine.  It  uses  a  home-grown  export  system  shell, 
capable  of  150  inferences  per  second,  with  a  forward- 
chaining  inference  engine  and  an  explanation  facility.  Its 
rules  are  elaborated  in  LISP,  and  statistical  user  profiles 
are  maintained  in  LISP  structures.  The  rules  are  compiled 
for  fast  performance.  At  the  time  of  writing,  MIDAS  in¬ 
cludes  about  10  rules, 

MIDAS  is  based  on  Denning’s  intrusion-detention 
model  1 15],  MIDAS  monitors  at  the  user  command  lino 
level  and  logs  all  commands  used.  MIDAS  uses  four  types 
of  heuristic  rules: 

«  Immediate-  These  arc  hard-and-fast  rules  that  make 
no  use  of  information  of  past  or  expected  user  behav¬ 
ior.  They  are  intended  to  detect  those  events  that, 
considered  in  isolation  from  any  other  information, 
are  suspicious. 

•  Anomaly  These  rules  use  statistical  user  profiles  to 
delect  when  a  user’s  behavior  departs  from  a  pattern 
established  by  observing  past  behavior.  User  profiles 
are  updated  at  the  completion  or  a  user  session.  The 
profiles  contain  a  list  of  the  user’s  usual  commands, 
the  usual  access  times  and  location  for  the  user,  and 
the  expected  typing  rate  for  the  user.  MIDAS  also 
profiles  the  observed  behavior  of  remote  systems. 

•  System-wide  slate — MIDAS  also  call  maintain  a 
system-wide  profile  to  characterize  what  is  normal  for 
the  system  globally.  For  example,  an  unusually  high 
number  of  invocations  of  the  copy  command  might 
indicate  suspicious  activity. 

•  Sensitive  path — A  command  sequence  can  be  char¬ 
acterized  as  abnormal  if  its  probability  of  occurring 
is  sufficiently  low.  This  type  of  heuristic,  rule  can 
also  be  used  to  determine  whether  a  user’s  com¬ 
mand  sequence  is  similar  to  those  characterizing  a 
known  or  postulated  attack.  Attack  scenarios  are  ob¬ 
tained  through  interviews  with  system  security  olfi- 
ccrs,  hackers,  and  experts  in  penetration  testing.  Use 
of  the  sensitive-path  heuristic  rule  could  enable  MI¬ 
DAS  to  detect  an  attack  in  progress  before  the  dam¬ 
age  occurs.  The  sensitive-path  type  of  heuristic  rule 
is  not  currently  implemented  on  MIDAS. 
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MIDAS  combines  different  intrusion  indicators  to  decide 
whether  an  intrusion  is  occurring.  A  login  time  unusual  for 
a  given  user,  for  example,  is  not  alone  sufficient  to  raise  an 
alarm;  but  If  combined  with  other  anomalous  data,  how¬ 
ever,  MIDAS  might  decide  an  intrusion  was  in  progress, 

MIDAS’s  rules  attempt  to  detect  attempted  break-ins, 
masqueraders,  penetrators,  Trojan  horses,  viruses,  and  mis- 
use.  To  detect  attempted  break-ins,  MIDAS  uses  rules  in¬ 
volving  password  failure  on  a  system  account,  login  fail¬ 
ure  with  an  unknown  user  name,  login  attempt  from  out¬ 
side  the  continental  United  States,  and  login  attempt  to 
a  locked  account.  To  detect  masqueraders,  MIDAS  uses 
rules  involving  unusual  login  (e.g.,  time,  location,  termi¬ 
nal  type),  unusual  commands  or  command  patterns,  In¬ 
valid  commands,  and  user  logged  in  simultaneously  from 
different  locations,  To  detect  penetrators,  MIDAS  uses 
rules  Involving  attempted  use  of  sensitive  commands,  at¬ 
tempted  use  of  unauthorized  commands,  attempted  access 
to  sensitive  objects,  and  attempted  access  to  other  people's 
objects.  To  detect  misuse,  MIDAS  uses  rules  involving  re¬ 
source  overuse,  inactive  session,  and  command  out  of  scope 
for  project.  To  detect  Trojan  horses  and  viruses,  MIDAS 
uses  rules  Involving  attempted  modification  to  system  files 
and  programs  and  unusual  execution  of  predictable  com¬ 
mands  (e.g.,  who  taking  abnormally  long). 

A  preprocessor  on  the  Multlcs  system  formats  the  audit 
data  for  MIDAS.  The  preprocessor  collects  audit  data  from 
the  usual  Multlcs  auditing  program6  and  from  additional 
audit  collection  software  that  was  written  specifically  for 
MIDAS. 

In  its  current  implementation,  audit  data  are  accumu¬ 
lated  in  a  Multics  file  and  dumped  to  tape,  and  then  the 
tape  is  fed  into  MIDAS.  A  real-time  capability  is  planned 
for  u  later  implementation  phase. 

3.4  Ask  the  Experts 

TRW  is  developing  an  intrusion-detection  system  for  the 
U.S.  Government  using  traditional  expert  system  technol¬ 
ogy  (l7j,  The  expert  system  rules  attempt  to  character¬ 
ize  intrusions,  either  in  general  (what  TRW  calls  generic 
common-sense  rules),  for  the  particular  organization,  or  for 
the  particular  type  of  system  and  installation.  The  rules  are 
obtained  using  standard  knowledge-engineering  techniques 
such  as  interviewing  and  working  with  system  security  of¬ 
ficers.  Known  cases  of  intrusions  drive  the  selection  of  the 
rules.  The  system  security  officers  will  be  able  to  add  new 
rules  and  modify  old  rules  In  the  rule  base, 

This  expert  system  is  Intended  to  do  the  work  of  the  sys¬ 
tem  security  officer  whose  job  now  Is  to  flip  through  huge 
printouts  of  audit  trails  looking  for  problem  areas.  The 
benefit  from  the  system  Is  expected  to  be  twofold:  first,  it 
will  be  able  to  analyze  data  that  are  too  voluminous  for  the 
security  officer  to  thoroughly  analyze  and  to  spot  long-term 
trends;  and  second,  it  will  provide  a  degree  of  proficiency 
that  would  otherwise  be  scarce,  because  experienced  secu¬ 
rity  officers  are  rare. 

This  system  uses  the  audit  trail  already  produced  by 
the  monitored  system.  Once  suspicious  activity  has  been 
identified,  the  system  is  intended  to  be  used  to  build  a  case 


6Beeeu*a  Multics  is  •  B2  system,  Us  auditing  facilities  satisfy  the 
auditing  requirement!  for  B2  truited  computing  eyeteme  w  enumereted 
in  the  Department  o f  Dt/tnit  Trusted  Computer  Sytterr.  Evaluation 
Criteria  1 16]. 


against  the  intruder.  It  does  not  operate  in  real  time,  but 
after  the  fact  (like  the  security  officers  it  mimics). 

In  one  test,  a  feasibility  system  using  50  rules  exhibited 
a  false  positive  rate  of  about  12  percent,  but  detected  the 
one  intrusion  planted  in  the  500  test  cases.  In  addition, 
it  detected  at  least  one  problem  that  had  been  thus  far 
undetected.  A  prototype  system  is  under  development. 

3.5  NAURS 

The  Network  Auditing  Usage  Reporting  System  (NAURS) 
is  used  in  conjunction  with  the  Terminal  Access  Controller 
(TAC)  Access  Control  System  for  the  M1LNET  and  the 
ARPANET  (18,19). 

NAURS  monitors  network  activity  originating  from  the 
TACs  and  network  access  controllers  (NACs).  It  collects 
data  about  TAC/NAC  logins,  TAC/NAC  login  failures,  lo¬ 
gouts,  open  and  close  connections,  and  TACs  coming  on¬ 
line,  and  maintains  the  data  in  a  database.  NAURS  pro¬ 
vides  both  background  analysis  on  past  activity  and  real¬ 
time  analysis  of  current  use.  It  provides  periodic  audit  trail 
reports  and  real-time  reports  on  unusual  events,  triggered 
by  the  events  themselves.  Interactive  query  from  local  ter¬ 
minals  is  also  supported.  Incident  reports,  generated  every 
day  from  the  previous  day’s  audit  data,  Include  incidents 
that  satisfy  one  of  three  rules  about  the  number  of  simul¬ 
taneous  logins  and  duration  of  sessions. 

The  threats  addressed  are  twofold:  broak-in  by  an  out¬ 
sider  (who  has  discovered  ».  valid  TAC  Id  and  password)  and 
misuse  by  a  legitimate  user  (trying  to  break  into  various 
network  hosts).  (Authorized  TAC  users  are  not  generally 
registered  users  of  every  host  on  the  network.) 

A  prototype  NAURS  exists  on  a  separate  machine  from 
the  SRI-NIC  host,  NAURS  Is  not  accessible  for  remote  lo¬ 
gin  or  file  transfer  by  network  users.  A  planned  production- 
quality  NAURS  will  feature  redundancy  of  equipment,  dis¬ 
tribution  of  functionality  (five  dedicated  workstations  have 
been  proposed),  ability  to  perform  real-time  detection  of 
incidents,  and  redundancy  of  the  audit  database.  Plans 
include  reports  on  trends,  such  as  6-month  differential-use 
trends  of  port  usage  (number  of  logins,  length  of  sessions). 
Profiles  will  be  maintained  for  users  and  devices.  Some 
of  these  profiles  will  be  established  when  an  individual  be¬ 
comes  a  registered  user,  and  others  will  reflect  observed 
user  behavior  patterns,  Proposed  additional  incident  rules 
are  unexpected  host  connection  for  a  particular  user,  long 
idle  periods,  excessive  connect  time,  simultaneous  TAC  lo¬ 
gins  with  the  same  user  id  but  not  necessarily  from  the 
same  TAC,  excessive  number  of  simultaneous  logins  from 
the  same  TAC,  unusual  time  of  day  for  a  particular  user, 
excessive  number  of  unsuccessful  logins  from  the  same  TAC 
and  same  user  id,  excessive  number  of  unsuccessful  host  lo¬ 
gins  at  different  hosts,  and  excessive  number  of  successful 
host  logins  at  different  hosts  during  the  same  TAC  session. 

3.6  Keystroke  Dynamics 

International  Bloaccess  Systems  Corporation6  offers  a  suite 
of  products,  collectively  called  Bloaccess  System  2000, 
that  perform  intrusion-detection  using  keystroke  dynamics, 
Among  these  are  two  products  BloPassword  and  BioCon- 
tinuous  for  biometric  access  protection  for  IBM  personal 
computers  (PCs). 

6  Bioecciee,  BioPaeeword,  BioContinuoue,  and  BioNet  ere  trade* 
mark*  of  International  Bloacceea  Syeteme  Corporation. 

70 


Keystroke  dynamics  technology  is  based  on  the  “fist  of 
the  sender”  concept  from  the  days  of  the  telegraph  when 
Motse  Code  operators  could  identify  a  sender  by  listening  to 
the  incoming  signals.  BioPassword  produces  an  electronic 
signature  based  on  the  unique  typing  characteristics  of  each 
authorized  user  for  keystroke-dynamics  verification  of  user 
id  and  password.  BioPussword  is  implemented  on  a  board 
installed  in  the  CPU  socket  of  the  mother  board  of  IBM 
personal  computers;  no  special  keyboard  is  needed. 

A  user’s  electronic  signature  is  stored  in  nonvolatile 
memory  on  the  BioPassword  board.  The  first  time  a  per¬ 
son  logs  on  the  computer  following  installation  of  the  board, 
the  signature  is  developed  by  having  the  user  type  his  or 
her  id  and  password  repeatedly  (about  12  times).  Once  a 
user’s  electronic  signature  is  installed,  BioPassword  oper¬ 
ates  transparently  to  the  user. 

BioPassword  is  automatically  activated  when  the  work¬ 
station  is  turned  on  or  reset  or  when  a  user  logs  off,  and 
can  lie  invoked  by  software  for  rcvorilicalion  at  any  time. 
BioPassword  prompts  the  user  for  uu  id  and  password  and 
verifies  both  the  contents  and  keystroke  dynamics  of  each 
against  the  stored  electronic  signature,  letting  the  user  pro¬ 
ceed  wil.h  normal  work  only  if  the  verification  is  positive. 
Once  access  is  granted,  if  the  workstation  is  idle  for  a  pro- 
spccilied  period  of  time,  BioPassword  times  out  and  re¬ 
quires  rrveriiicatinn  of  the  user  before  continuation  of  the 
idled  job.  All  access  attempts  and  logins  are  audited. 

BioCoiilinuous  incorporates  all  of  the  features  of 
BioPassword  and  adds  continuous  real-time  verification  of 
users.  BioCoiilinuous  is  a  single-board  component  for  the 
IBM  PC.  With  its  own  high-speed  processor,  the  UioCon- 
tinuous  hoard  continuously  verifies  a  user’s  identity  in  par¬ 
allel  with  the  user’s  work  on  the  PC’s  processor,  using  over 
110  typing  characteristics,  including  intervals,  rhythm,  an 
analog  of  pressure,  ami  error  characteristics.  After  devel¬ 
oping  an  electronic  signature  for  a  user  id  and  password, 
BioConlinuous  develops  an  extended  electronic  signature 
for  each  user.  This  extended  electronic  signature  contains 
additional  biometric  signature  data  that  match  a  user’s 
keystroke  characteristics  used  in  normal  work.  The  learn¬ 
ing  process  takes  place  over  a  few  days,  and,  once  the  learn 
ing  process  is  completed,  the  user’s  keystroke  dynamics  are 
automatically  and  continuously  verified  against  his  or  her 
extended  electronic  signature. 

BioConliiiuoiis  includes  a  programmable  security  matrix 
containing  information  that  indicates  what  actions  arc  to 
be  taken  when  a  possible  intruder  is  detected.  The  action 
can  depend  on  risk  factors,  such  as  which  data  arc  being 
accessed  or  which  function  is  being  performed.  Thresholds 
and  alarms  can  be  preselected. 

International  Bioaccess  Systems  Corporation  is  develop¬ 
ing  a  product  called  BioNet  that  will  add  flexibility  to  PCs 
connected  to  a  local  area  network  by  providing  a  central 
storage  of  electronic  signatures.  This  will  allow  authorized 
users  to  use  any  workstation  oil  the  network  without  hav¬ 
ing  to  store  their  electronic  signatures  on  each  workstation. 
BioNet  also  will  provide  for  integrated  auditing  of  an  in¬ 
dividual  user’s  activity  across  all  the  workstations  on  the 
local  network. 


tomers  [20].  In  such  an  environment,  the  customers  may 
not  be  as  concerned  with  safeguarding  the  security  and  in¬ 
tegrity  of  the  service  provider’s  system  and  information  as¬ 
sets  as  would,  say,  those  users  (employees  of  the  service 
company)  who  create  and  maintain  that  information  asset. 
Thus,  the  customer  cannot  be  relied  upon  in  any  program 
of  security  instituted  at  the  service  company.  The  threat  is 
that  subscribing  customers  may  give  away  their  passwords, 
or  lend  their  terminal  devices,  to  would-be  intruders.  Thus, 
Discovery  attempts  to  detect  imposters  who  have  obtained 
legitimate  user  ids,  access  codes,  and  inquiry  formats.  The 
perceived  need  was  for  an  intrusion-detection  mechanism 
that  operates  transparently  to  the  subscribers  of  the  ser¬ 
vice.  The  goal  is  that  Discovery  become  a  preventive,  sis 
well  as  a  detective,  control. 

Discovery  Is  an  expert  system  that  searches  for  fre¬ 
quently  occurring  patterns  in  subscriber  inquiries  to  the 
data  and  compares  these  patterns  to  daily  subscriber  in¬ 
quiry  activity  to  detect  variances  in  normal  subscriber  be¬ 
havior.  It  develops  a  user  proiile  for  eacli  customer  by  type 
of  service  and  access  method,  and  updates  a  user’s  profile 
daily  if  there  lias  been  activity  for  the  user  access  code  that 
day. 

Discovery  Is  system-specific  in  that  the  intrusion- 
detection  ruleB  are  particular  to  the  spcciiic  application- 
dependent  data  fields,  or  variables,  being  monitored.  How¬ 
ever,  Discovery  also  monitors  some  variables  that  are 
generic  to  most  computer  systems,  such  as  date  and  time 
of  access,  type  of  access,  user  location,  user  identifier,  pass¬ 
word,  and  port  identifier.  Discovery  allows  the  security  offi¬ 
cer  to  choose  the  variables  to  be  monitored  and  the  thresh¬ 
old  parameters,  so  that  the  system  can  be  fine-tuned  and 
the  impact  of  adding  now  services  can  be  determined.  The 
security  oliicer  cun  also  modify,  delete,  and  add  variables 
to  be  monitored  as  service  offerings  change.  Tile  thresholds 
can  be  set  individually  for  each  variable  being  monitored 
for  eacli  user  access  code. 

Discovery  analyzes  the  daily  inquiry  activity  for  each 
user  access  code  for  comparison  with  the  established  pro¬ 
file  for  tile  customer  and  also  for  comparison  with  a  model 
of  illegitimate  access.  Discovery  only  analyzes  correct  in¬ 
quiries  submitted  by  customers;  thus  Discovery  cannot  use 
error  patterns  as  indicators  of  intrusions.  Discovery  records 
all  inquiries  that  fall  outside  of  acceptable  thresholds,  and 
provides  an  explanation  for  why  the  inquiry  is  unaccept¬ 
able  (these  are  not  used  in  updating  the  customer’s  proiile). 
Discovery  is  not  a  real-time  system,  but  alerts  the  security 
officer  to  unusual  activity  at  the  end  of  the  workday. 

While  Discovery  was  under  development,  a  prototype 
was  used  to  parallel  the  work  or  security  investigators,  in 
order  to  ensure  that  Discovery  would  make  the  same  deci¬ 
sions  as  the  investigators.  TRW  found  that  tile  use  of  Dis¬ 
covery  resulted  in  investigative  leads  being  developed  more 
quickly,  and  the  analysis  of  Discovery’s  exception  data  pro¬ 
vided  more  concise  leads  than  did  the  investigators’  con¬ 
ventional  methods.  Other,  unexpected,  benefits  included 
the  ability  to  perform  marketing  analysis  on  detailed,  up- 
to-the-minute  data  using  Discovery’s  customer  usage  pat¬ 
terns.  Trends  can  also  be  observed  by  comparing  current 
customer  usage  data  with  previous  usage  data. 


3.7  Discovery 

Discovery  is  ail  intrusion-detection  export  system  developed 
by  TRW  to  address  the  intrusion  threat  in  an  environ¬ 
ment  in  which  computer  services  are  sold  to  outside  cus¬ 


3.8  Cly  'e  Digital  Systems’  Audit 

Ciyde  Digital  Systems’  Audit  is  a  product  that  audits  users 
of  VAX/VMS  machines.  Audit  can  create  a  complete  log 
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of  all  terminal  input  and  output  and  provides  procedures 
to  help  analyze  the  data  collected. 

Audit  can  record  every  byte  that  passes  between  a  user’s 
terminal  and  the  system,  including  control  and  escape  se¬ 
quences,  and  stores  this  data  in  a  file,  although  certain 
qualifiers  can  be  specified  so  that  particular  special  char¬ 
acters  can  later  be  discarded  from  the  audit  log  file  (for 
ease  of  display  and  formatting,  for  example).  Audit  also 
provides  the  option  to  monitor  only  terminal  input  (from 
the  user). 

Audit  also  provides  a  flexible  capability  for  selective  au¬ 
diting.  For  example,  auditing  can  be  activated  selectively 
for  terminal  sessions  satisfying  certain  criteria,  such  as  for 
specific  users,  or  specific  times  of  day  (producing  an  audit 
trail  for  the  user's  terminal  session),  and  the  use  of  spe¬ 
cific  programs  can  also  be  selectively  audited  (producing 
an  audit  trail  for  the  specified  program). 

Auditing  can  be  controlled  by  VMS-format  keyboard 
commands  or  from  programs. 

Audit  allows  analysis  of  the  audit  data  by  random  sam¬ 
pling  or  tli rough  selective  analysis  based  on  the  system 
manager’s  knowledge  of  external  events.  Audit’s  analy¬ 
sis  produces  three  reports:  a  security  summary  report, 
which  summarizes  the  activity  of  high-risk  users  (as  de¬ 
fined  by  a  predetermined  set  of  14  risk  factor  tests  and 
a  programmable  set  of  weighting  parameters);  u  security 
event  report,  which  summarizes  the  events  that  caused 
those  users  to  he  considered  high-risk;  and  a  supporting 
data  report,  which  includes  data  from  the  audit  log  to  sup¬ 
port  the  conclusions  of  the  first  two  reports.  The  risk  fac¬ 
tors  for  which  Audit  tests  include  sessions  outside  business 
hours  or  on  weekends  or  holidays  (the  definition  of  normal 
business  hours  and  holidays  can  be  selected  by  the  system 
manager);  sessions  indicating  use  of  the  AUTUORI'AH  or 
SYSGEN  utilities;  sessions  indicating  browsing;  file  access 
alarms;  other  alarms  (alarms  cun  be  established  for  certain 
activities);  repeated  unsuccessful  login  attempts;  sos'>ioiis 
with  dial-up  or  remote  terminals;  simultaneous  logins  for 
the  same  user;  and  attempts  to  turn  oil  auditing.  Some  of 
Audit’s  14  tests  use  data  contained  in  die  audit  logs,  and 
some  use  information  from  the  VMS  operator  log  file;  no 
lest  uses  data  from  both.  The  operator  log  file  is  used  to 
test  for  file  access  alarms,  other  alarms,  login  failures,  ami 
attempts  to  turn  off  auditing,  The  other  tests  use  the  audit 
logs. 

Each  of  the  14  tests  has  an  associated  weight  and  three 
factors.  One  factor  is  for  after-hour  use;  one  factor  is  Tor 
activity  from  a  dial-up  terminal;  ami  one  factor  is  for  ac¬ 
tivity  from  a  DECnet  remote  terminal.  Whenever  an  event 
satisfies  one  of  the  tests,  its  weight  is  multiplied  by  its  rel¬ 
evant  factors  and  the  result  is  added  to  the  score  for  that 
user.  Users  with  sufficiently  high  scores  are  considered  to 
be  high-risk .  The  weights  and  factors  can  be  selected  by 
the  system  manager.  The  system  manager  can  also  add 
additional  tests. 

There  has  been  at  least  one  published  report  of  bypasses 
of  certain  Audit  tests  (21).  Allen  Clyde  reports  that  Au¬ 
dit  lias  detected  “numerous  acts  of  misconduct,  including 
criminal  conduct  ...  on  sensitive  computer  systems”  [22[. 

4  Conclusions 

None  of  the  intrusion-detection  approaches  described  is  suf¬ 
ficient  alone — each  addresses  a  different  threat.  A  success¬ 


ful  intrusion-detection  system  should  incorporate  several 
different  approaches.  In  particular,  a  statistical  user  profile 
approach  augmented  with  a  rule- base  that  characterizes  in¬ 
trusions  promises  to  be  an  effective  combination.  Because 
they  use  this  combination  of  approaches,  two  prototype 
systems — IDES  and  MIDAS — have  the  potential  to  become 
strong  intrusion-detection  systems.  Of  these  two,  IDES 
is  particularly  strong  in  its  statistical  approach,  whereas 
MIDAS  focuses  primarily  on  enumerating  a  comprehensive 
(although  site-specific)  set  of  expert  system  rules. 

Although,  as  Linde  notes  j23|,  the  more  skilled  penetra- 
tor  can  disable,  the  auditing  mechanisms  in  order  to  work 
undetected,  auditing  and  intrusion-detection  mechanisms 
are  stil.1  of  value  in  detecting  the  less  skilled  pcnctrator, 
because  they  increase  the  difficulty  of  penetration. 
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Abstract  -  The  tv! allies  Intrusion  Detection  and  Alerting  System 
(MIDAS)  is  an  expert  system  which  provides  real-time  intrusion  and 
misuse  detection  for  the  National  Computer  Security  Center's  net¬ 
worked  mainframe,  Dockmastcr,  a  Honeywell  DPS-8170  Muhics. 
The  basic  design  of  MIDAS  was  heavily  influenced  by  the  intrusion 
detection  research  of  Dorothy  Denning  and  Peter  Neumann  of  SRI 
International.  They  proposed  that  statistical  analysis  of  computer 
system  activities  could  he  used  to  characterise  normal  system  and 
user  behavior.  Given  such  statistical  profiles ,  user  or  system  activity 
that  deviates  beyond  certain  hounds  should  be  detectable.  MIDAS 
has  been  developed  to  employ  this  basic  concept  in  its  evaluation  of 
the  audited  activities  of  more  than  1200  Dockmastcr  users. 


Introduction 

The  annoying  ring  of  the  telephone  jarred  John  out  of  his 
contemplation  of  the  Monday  morning  newspaper.  One  of  his 
staff  answered,  then  handed  him  the  phone,  whispering  "It’s  the 
Chief”. 

"Computer  Center,  John  Speaking." 

"Hello,  John?  This  is  Edward." 

"Hi,  fid.  What’s  up?",  replied  John,  trying  to  sound  casual. 
By  the  tone  of  Edward's  voice,  John  could  tell  lie  was  upset. 

"John,  I  just  got  acall  from  Carla  in  Marketing.  She  says  she 
got  a  message  when  she  logged  on  this  morning  about  having 
been  logged  in  over  the  weekend.” 

"Boy,  that's  Carla  for  yah  always  so  darned  dedicated...", 
John  said,  frantically  trying  to  think  of  something  to  say  to  dis¬ 
tract  Edward.  I  fc  knew  what  was  coming. 

"She  says  she  wasn’t.” 

"She  says  she  wasn’t  what?" 

"She  says  she  wasn't  on  the  system  over  the  weekend." 

"Oh." 

"You  people  are  paid  to  take  care  of  this  system.  Why  can’t 
you  get  your  act  together  down  there!",  said  Edward,  starting  to 
networked  up.  "Don't  you  ever  monitor  who’s  logged  on?  Carla 
has  access  to  some  of  this  company’s  most  sensitive  informa¬ 
tion!  Why  is  it  that  wc  never  know  when  we’ve  been  had  until 
someone  steps  up  and  tells  us!  We  look  like  blithering  idiots!" 

"Now  hold  on,  Edward !  Sure  the  system  monitors  who  logs 
on;  licck,  it  even  keeps  track  of  the  misspelled  commands,  the 
access  errors,  and  half-a-dozen  other  things.  But  with  the,  num¬ 
ber  uf  users  on  our  system,  wc  simply  don ’t  have  the  manpower 
to  pour  over  those  logs  day  in  and  day  out."  But  even  as  he  said 
it,  John  knew  that  wasn't  true.  Not  even  an  army  of  workers 
would  be  able  to  make  sense  out  of  the  mountains  of  log  data  that 
poured  out  of  the  system  every  day.  More  staff  wasn't  the 
answer,  but  John  didn’t  know  what  was. 

"Don’t  start  on  me  again  with  that  whining  for  more  help. 
Your  department’s  overstaffed  in  the  first  place!  And  top  heavy, 
too!  Whydon't  you  try  doing  yourjob  for  a  change!" 


The  phone  went  dead  in  John’s  hand.  "OK  troops,"  he  said, 
turning  to  his  staff  with  a  heavy  sigh,  "let’s  get  out  the  logs  for 
this  weekend  and  see  what  we  can  find..,*. 

Intrusion  Detection 

Audit  trail  analysis  seems  to  be  like  the  proverbial  sour 
grapes;  it  is  so  difficult  to  obtain  that  it  is  templing  to  dismiss  it 
as  unprofitable  and  abandon  any  further  attempt  at  it.  The  fac¬ 
tors  that  make  audit  trail  analysis  so  difficult  may  be  sum¬ 
marized  into  three  broad  categories;  the  lack  of  adequate  and/or 
appropriate  audit  data;  the  inability  of  system  security  officers 
to  utilize  available  data;  and  the  lack  of  a  precise  definition  of 
what  to  look  for. 

"Feast  or  Famine"  characterizes  the  audit  trail  data  of  typi¬ 
cal  systems.  Many  systems  do  not  provide  adequate  auditing 
facilities  to  be  able  to  detect  a  penetration  or  abuse  by  audit  data 
analysis;  these  are  the  famine  systems,  In  other  systems,  the 
security  officer  is  inundated  with  page  upon  page  of  audit  data 
until  buried  under  a  paper  mountain;  these  are  the  feast  systems. 
There  is  a  variant  of  this  latter  category  which  allows  audit  sour¬ 
ces  to  be  selectively  activated,  but  even  this  is  not  the  solution. 
In  such  systems  the  security  officer  is  faced  with  the  unattractive 
prospect  of  having  to  decide  which  features  to  activate  at  the  risk 
of  failing  to  activate  the  audit  facility  that  would  have  provided 
the  key  bit  of  data  necessary  to  detect  and  apprehend  a  system 
pcnctrator. 

Even  if  a  system  were  developed  which  provided  just  the 
right  kind  and  amount  of  audit  data,  the  security  officer  still  has 
a  formidable  task,  for  only  the  most  blatant  of  attacks  will  bedis- 
cerniblc  through  scrutiny  of  a  single  day’s  audit  data.  The 
sophisticated  pcnctrator  will  spread  out  his  activity  over  a  num¬ 
ber  of  days  or  weeks.  They  will  subtly  exploit  the  dark  corners 
of  a  system.  For  the  security  officers  to  detect  such  attacks  would 
require  the  correlation  and  recall  of  an  incredible  store  of  data; 
nothing  short  of  a  Herculean  feat. 

Another  problem  complicating  the  task  of  security  officers 
in  their  attempts  to  analyze  audit  data  is  the  imprecise  definition 
of  what  characterizes  the  threat  they  are  attempting  to  counter. 
Anderson  1 1 2]  defines  the  threat  that  monitoring  system  activity 
is  expected  to  counter  as; 

"The  potential  possibility  of  a  deliberate  unauthorized  at¬ 
tempt  to; 

a)  access  information 

b)  manipulate  information 

c)  render  a  system  unreliable  or  unusable 

But  what  does  an  intrusion  look  like  in  terms  of  theaudit  data 
generated?  How  can  we  differentiate  between  authorized  use 
and  the  unauthorized  threat  just  described?  These  are  certainly 
not  easy  questions  to  answer,  but  they  lie  at  the  heart  of  any  at¬ 
tempt  to  automate  audit  analysis  aids. 

Studying  the  activity  of  a  successful  security  officer  in¬ 
volved  in  audit  trail  analysis  may  reveal  an  approach.  Consider 
the  process  followed  by  a  security  officer  in  tracking  down  the 
hacker  that  has  just  scribbled  all  over  his  company's  payroll 
database.  First,  he  applied  a  rule  of  thumb,  or  heuristic,  that  most 
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penetration  attempts  occur  in  the  early  hours  of  the  morning 
when  the  system  is  unattended,  so  he  concentrated  his  search  on 
sessions  in  that  time  period.  Next,  since  the  only  users  at  that 
hour  were  connecting  to  the  system  across  a  network,  he  looked 
for  individuals  whose  point  of  origin  fluctuated.  His  reasoning 
here  was  that  someone  illegally  penetrating  the  system  would  at¬ 
tempt  to  cover  his  actions  by  varying  the  network  path.  These 
two  constraints  yielded  a  set  of  potential  accounts.  From  these 
he  was  able  *n  pinpoint  the  account  that  had  been  compromised 
because  the  audited  activities  of  the  individual  using  it  simply 
didn’t  feel  right"  for  the  particular  account.  He  immediately 
shut  down  that  account  and  had  a  long  talk  with  the  account 
holder  v.  ho  eventually  admitted  to  giving  his  password  to  his 
roommate,  a  computer  "enthusiast".  From  this  exampie  we  can 
see  it  the  reasoning  process  employed  by  successful  system 
set  ■'  y  officers  iu solves  symbolic  reasoning,  heuristics  and 
uncertainty.  This  emphasis  on  knowledge  and  its  application 
through  symbolic  reasoning  makes  intrusion  detection  at.  10- 
propriaie  candidate  for  expert  systems  (8). 


Expert  Systems 


The  gi'jl  of  any  inf  >  ion  dcu.-ction  system  must  be  to  aid 
system  «<v;ur;ty  officers  in  the  detection  ot  penetration  and 
abu.«e  Tiic  srnen  system  shnyM  provide  the  knowledge  of  an 
"expert  "  secur  ity  officer.  This  is  a  MINIMUM  standard  of  per¬ 
formance  for  an  intrusion  .1. lection  system;  as  already  dis¬ 
cus  .a  (i,  human'-  generally,  'u;’ulo  a  very  •  rod  job  of  audit  trail 
ar,  af  ..  The  u  :t  of  penetr  ,■  c on  s  or  abuses  detected  by  a  security 
officer  s  ith  the  aid  of  the  automated  system  should  be  a  super¬ 
set  of  those  that  would  have  been  detected  by  the  security  officer 
unaided. 

Codification  .iiuir-  'plication  of  knowledge  under  similar 
circumstances  ■’  -  ■.  ■'■sis  of  on  expert  system.  This  knowledge 
is  encoded  in  i.  v  f.-rm  of  facts  (assertions  about  the  state  of  a 
problem  solution)  a  id  heuristics  (ades  which  govern  the  trans¬ 
formation  of  the  solu'  oti  state)  Expert  systems  have  been 
developed  that  have  nccei.’.plished  amazing  results  in  a  number 
of  dilferent  field;:  \'j,  3, 1 1  ]).  MIDAS  is  in  exampie  of  such 

a  system  to  detect  inuu  ions  into  a  mmpuiei  system. 

HIMSJMisu 

Get  place  and  wealth ,  if  possible, 
with  grace ; 

If  not,  by  any  means  pet  wealth 
and  place, " 

-  King  Midas 

The  Multics  Intrusion  Deti--.'.ion  and  Alert  fug  System 
(MIDAS)  provides  real-time  intrusion  and  misuse  detection  for 
th;  National  Computer  Security  Center's  networked 
mb  ,.var,te,  Doc'mtastcr.  Dockmaster  is  a  Honeywell  Multics 
comm  ter  system  employed  primarily  as  an  electronic  com¬ 
munications  meentunsm  foi  the  national  computer  security 
comm  ■  tty.  MIDAS  was  developed  using  the  Production- 
Based  Expert  Sy-tem  Toolset.  V-BE.r.T),  an  in-house  expert  sys¬ 
tem  shell  tha,  privies  the  i  .hanisms  for  developing, 
compiling  ano  debugging  very  powerful  ruleseu,  The  P-BEST 
inference  engine  controls  the  assertion  of  data  into  the  MID  AS 
knowledge  base,  and  via  its  forw.  iu  chaining  inference  engine, 
directs  rule  selection  and  execution. 


The  basic  design  of  MIDAS  was  heavily  influenced  by  the 
seminal  work  in  this  area  of  J.  P.  Anderson,  the  intrusion  detec¬ 
tion  research  of  Dorothy  Denning  and  Peter  Neumann  of  SRI  In¬ 
ternational,  and  similar  efforts  at  Sytek  [13],  Denning  and 
Neumann  proposed  that  statistical  analysis  of  computer  system 
activities  could  be  used  to  characterize  normal  system  and  user 
behavior  (see  [2, 1]).  Given  such  statistical  profiles,  user  or  sys¬ 
tem  activity  that  deviates  beyond  certain  bounds  should  be 
detectable.  MIDAS  has  been  developed  to  employ  this  basic 
concept  in  its  evaluation  of  the  daily  activities  of  more  than  1 200 
network  users. 


Architecture 


System  Security  Monitor 


Figui  •  1  MIDAS  Architecture 


MIDAS  consists  of  a  number  of  distinct  parts,  including:  a 
command  monitor  t  CM)  that  captures  command  execution  data 
not  audited  by  Multics  systems;  a  preprocessor  (preproc)  for 
transforming  Dockmaster  audit  log  entries  into  a  canonical 
form;  a  network-interface  daemon  (Net);  a  statistical  database 
of  recorded  user  and  system  statistics  (STAT);  aknowledge  base 
consisting  of  a  representation  of  current  fact  base  (FB)  and  rule 
base  (RB);  and  an  extensive  end-user  interface  forcornmunieat- 
ing  with  system  security  officers.  The  preprocessor,  command 
monitor,  and  network  daemon  reside  on  Dockinaster;  the 
MIDAS  knowledge,  statistical  base,  and  user  interface  are  in¬ 
stalled  on  a  S ymbolics  Lisp  machine. 

Each  time  an  audit  record  or  command  monitor  recoid  is 
generated,  t1'  ''.‘eprocessor  filters  out  unnecessary  data  and 
transforms  .  -  <inder into  a  MIDAS  assertion.  The  assertion 

is  handed  to.  .work  interface  daemon  and  passed  via  local 
area  network  to  the  Symbolics  lisp  machine  hosting  the  expert 
system.  T.  -s  fact  is  placed  into  the  fact  base  of  the  expert  system. 
This  iii.rod'iction  of  a  fact  into  the  expert  system  will  cause  the 
creation  of  rule -fact  bindings  between  the  fact  and  all  matching 
rules  in  the  rule  base.  Assertion  of  this  tact  may  satisfy  the  firing 
conditions  of  one  or  more  rules.  Any  such  rules  will  then  fire, 
potentially  transforming  die  state  of  ihe  system  Depending 
upon  the  nature  of  the  fact,  ii  could  cause  a  chain  of  rule  firings 
resulting  in  a  number  of  potential  system  responses,  ranging 
from  woj  ning  the  operators  of  suspicious  activity  to  taking  direct 
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action  to  stop  a  penctrator.  The  system's  reaction  is  proportion¬ 
al  to  the  extent  that  the  monitored  activity  deviated  from  what  is 
considered  ‘normal '  according  to  the  relevant  statistical  profile. 

MIDAS  statistics  recor.l  the  aggregation  of  monitored  sys¬ 
tem  activity.  Comparing  norms  derived  from  past  activity  ag¬ 
gregation  to  ongoing  actions  determines  whether  the  current 
activity  is  outside  some  standard  deviation.  MIDAS  keeps  both 
user  and  system-wide  statistics.  User  profile  statistics,  which 
define  normal  behavior  for  a  user  are  maintained  (in  monthly  ag¬ 
gregate  form)  for  each  user  account  throughout  the  life  of  the  ac¬ 
count.  These  statistics  are  updated  as  user  behavior  changes. 
MIDAS  also  keeps  current  session  activity  data  in  a  session 
statistics  structure  which  is  maintained  forthedurationofauser 
session.  User  session  statistics  are  initialized  at  login  from  the 
data  extracted  from  user  profile  statistics.  Session  statistics  in¬ 
clude  the  calculated  values  that  act  as  thresholds  of  concern  for 
all  activities  monitored  for  that  user.  For  example,  if  an 
individual’s  user  statistics  indicate  that  during  his  350  sessions 
lie iggered  an  as  erage  38  system  errors,  with  a  standard  devia¬ 
tion  of  20;  a  system  error  concern  threshold  of 58(38+ 2ft)  would 
be  stored  in  his  session  statistics  profile. This  value  would  be  the 
upper  limit  for  normal  activity  --  if  this  limit  were  exceeded 
suspicion  would  be  aroused,  and  action  might  be  taken  in  the 
form  of  messages  to  the  operator  or  by  the  assertion  of  a  fact 
noting  the  so  ipicion  into  the  knowledge  base.  When  the  user 
logs  out,  the  user  statistical  profile  is  ujxlated  to  incorporate  the 
statistical  variance  that  has  been  developed  from  the  user's  ac¬ 
tivity  during  the  session.  Figure-  2  illustrates  the  cycling  of  in¬ 
dividual  user  statistics. 


a  small  number  of  data  items  in  their  analysis;  and  they  are  static 
in  that  they  do  not  make  use  of  any  statistical  information.  In  ef¬ 
fect,  they  are  intended  to  detect  those  audit  log  entries  that  are, 
in  isolation  of  any  otherinformation,  anomalous  enough  to  raise 
concern. 

Figure  3  gives  an  example  of  this  type  of  heutistie  encoded 
in  the  P-BEST  language,  This  rule  concerns  attempted  system 
breakin.  The  rule  monitors  the  knowledge  base  waiting  for  the 
assertion  of  a  bad  login  attempt  in  which  the  account  specified 
by  some  user  was  invalid,  but  commonly  used  on  other  systems 
to  denote  a  privileged  account.  When  the  rule  finds  such  an 
assertion  it  will  warn  the  MIDAS  operator  and  "remembe." 
another  fact;  namely,  that  with  high  probability,  a  breakin  at¬ 
tempt  has  occurred. 

(def  rule  illegaLpriviIeged_accoufit  states 
if  there  exists  a  failedjoginjtem 

such  that  name  is  ("root"  or  “superuser" 
or  "maintenance"  or  "system")  and 
time  is  ?time. _stamp  and 
channel  is  ?channel 
then 

(print  "WARNING:  ATTEMPTED  LOGIN  TO 
PRIVILEGED  ACCOUNT") 
and  remember  a  breakin_attempt 
with  certainty  ‘high* 
such  that  attack  time  is  ?time  stamp 
and  login_channel  is  ?channel) 


CUKATK 


Figure  2  User  Statistics  Cyi  L 

MIDAS  maintains  similar  statistical  stiuc'urcs  to  determine 
system  Vii-lt  ..C tic  I ly  mums. 


Heuristics 

lhe  logical  '’rue  lure  of  the  MIDAS  i  ^  ;em  revolves  around 
tlic  rules  ( heuristics)  in  the  rule-base.  These  rules  may  be  charac¬ 
terized  in  two  ways:  according  to  the  type  of  heuristics  they 
employ,  or  according  to  the  articular  area  of  surveillance  they 
address. 

There  are  three  basic  types  of  heuristics  employed  to  review 
audit  data  under  MIDAS:  immediate  attack  heuristics,  user 
anomaly  heuristics,  and  system  state  heuristics. 

Immediate  Attack  -  Immediate  attack  heuristics  represent 
a  superficial  level  of  analysis.  These  rules  operate  with  a  very 
narrow  view  of  the  data  and  are.  in  some  sense,  static  in  their  in¬ 
terpretation  They  are  narrow  in  that  they  generally  involve  only 


Figure  3  Immediate  class  rule 

User  Anomaly  •  User  anomaly  heuristics  make  use  of  the 
statistical  proliles  to  detect  anomalous  user  hehav  'or.  1  hey  en¬ 
code  the  intuition  of  the  security  officer  when  he  says,  “it  just 
doesn't  feel  right."  Figure  J  illustrates  this  soil  o!  rule.  In  this  ex¬ 
ample,  the  rule  is  concerned  with  user  logon  analysis. 

(defrule  unusualjogin  .time  states 
if  there  exists  a  login  entry 
such  that  user  is  ?usertd  and 
time_stamp  is  ?login  time 
and  (unusualjogin  Jime  ^userid  ?login  time) 
then 

remember  a  user  login_  anomaly 
such  that  user  is  ?userid  and 
time  stamp  is  ^loginjime) 

Figure  4  Anomaly  class  rule 

1  his  example  incorporates  the  notion  of  a  usual 'login  time 
fora  user.  If  a  user  accesses  the  system  outside  his  normal  hours, 
then  an  anomaly  record  would  be  generated.  This  would,  in  cf 
feet,  trigger  a  heightened  level  of  suspicion  about  that  user. 

System  State  -  System  state  heuristics  are  analogous  to 
anomaly  heuristics,  except  that  they  characterize  what  is  normal 
for  the  entire  system.  One  example  of  this  type  of  rule  is  the 
detection  of  an  inordinately  large  number  of  login  failures  sys¬ 
tem-wide.  Such  an  occurrence  might  be  indicative  of  an  attempt 
to  break  into  the  system. 


In  addition  to  the  categories  of  heuristics,  Denning  defined 
eight  general  areasofeoneem:  breakin,  masquerading,  penetra¬ 
tion,  leakage,  database  inference, Trojan  horse,  virus,  and  denial 


of  service  |2|.  Under  MIDAS,  Trojan  horse  and  virus  attacks  arc 
collapsed  into  a  single  category  because  of  their  similarities. 
Also,  since  our  concern  is  mainly  with  operating  system 
penetration,  as  opposed  todatabase  compromise,  inference  type 
attacks  arc  not  considered.  Finally,  denial  of  service  concerns 
and  leakage  concerns  are  combined  with  misuse  concerns. 
Together  with  the  heuristics  described  above,  these  concerns 
define  a  matrix  which  outlines  the  intended  coverage  of  the 
MIDAS  system. 


IMMEDIATE  ANOMALY _ SYSTEM 


BREAK-IN  o 

MASQUERADE  o 

PENETRATION  o  o 

MISUSE  o 

TROJAN  I iORSE  o 


o 


o 

o 


o 


o  =  rule  coverage 


if  he  directs  his  printer  output  to  some  location  other  than  where 
he  normally  sends  output,  lie  may  be  attempting  to  leak  sensitive 
data  |2|.  Simple  inactivity  (loggingon  and  then  wandering  away 
from  the  terminal),  while  not  an  attack,  represents  wasted 
resource  and  a  potential  security  compromise.  As  such  it  is  noted 
and  reported  by  the  system.  This  area  of  concern  also  covers 
basic  detection  of  covert  channel  activity.  Under  Multics 
release  11.0,  all  large  covert  channels  (bandwidth  1  (X)  BPS) 
have  been  eliminated.  Moderate  (10-  UK)  BPS)  and  small  (1  - 
10  BPS)  channels  are  captured  and  audited  by  Multiis  [4). 
These  MIDAS  rules  act  on  the  occurrence  of  audited  covert 
channel  activity. 

Trojan  Horsc/Virus  -  This  area  of  concern  involves  the 
detection  of  a  Trojan  horse  or  virus  which  has  been  introduced 
into  the  system.  These  two  areas  are  not  separate  because  we 
have  not  determined  a  way  to  differentiate  between  them  given 
the  available  audit  data.  The  key  factors  which  are  considered 
when  addressing  this  concern  are  access  violations  on  system 
sensitive  objects,  and  execution  statistics  which  violate  norms 
established  tor  given  commands.  Access  violations  on  sensitive 
objects  may  indicate  the  introduction  of  a  virus  into  the  target 
system;  monitoring  execution  statistics  attempts  to  detect  their 
presence. 


Figure  5  Coverage;  of  MIDAS  Heuristics 


Attempted  ltreukin  I  liisare.inlcoiiictiilocuxesprimnti 
ly  on  login  failure's.  An  example  of  this  kind  of  heuristic  was  ii 
Instated  in  tigure  .?. '!  Ins  rule  Hags  login  failures  on  restricted 
account  names  (such  as  'supetuser'.  or  Toot')  as  being  suspi 
cious. 

Another  level  of  analysis  involves  monitoiiug  parameters 
which  detine  the  state  ol  the  entire  system  at  any  given  time.  It 
the  attacker  weie  smait  enough  to  vat y  the  target  accounts,  the 
s\  stem  rules  would  still  detect  the  abnormal  behavior  by  the  rise 
in  system  w  ide  login  failures. 

Other  examples  tiom  ibis  concent  aiea  include;  flagging 
excessive  password  I  ail  uie  son  u  system  account  and  noting  ex¬ 
cessive  or  abnormal  password  failure  on  other  accounts. 

Masquerade  I  Ins  men  ol  concern  involves  the  detection 
ol  intruders  who  hast  obtained  access  to  accounts  and  valid 
passwords  w  Inch  do  not  belong  to  them.  Detecting  such  occur¬ 
rences  is  stiaiglitlorwaid:  it  is  based  upon  the  assumption  tli.it 
parameters  gleaned  Iron)  a  user's  normal  interaction  with  the 
system  may  he  used  to  spoi  aetis  its  attributed  to  lh.it  user  but 
which  deviates  trom  the  user  's  statistical  nouns.  A  number  ol 
statistical  measures  Uir  a  variety  of  factors  are  collected  and 
stored  t  or  each  valid  u.  cr  account.  Some  examples  of  these  fac¬ 
tors  include;  origin  ol  connection  (for  network  users),  login 
time,  resource  usage,  command  usage,  and  command  errors. 
Both  tire  average  measure  tor  each  factor  and  the  normal  devia 
non  is  recorded. 

During  a  login  session.  MIDAS  continually  monitors  the 
statistics,  of  die  current  nseis  and  compares  them  against  llieii 
usei  profiles.  If  a  user's  eurient  activity  exceeds  acceptable 
limits  suspicion  is  aroused.  An  example  of  this  type  of  rule  was 
given  in  figure  4 

Penetration  -  Penetration  concern  involves  the  detection  of 
any  attempted  violation  of  system  security  mechanisms,  and  is 
applicable  to  valid  users  as  well  as  masqueraders.  This  area  of 
concern  ir  addressed  by  immediate,  anomaly,  and  system  wide 
heuristics  targeted  toward  access  or  attempted  access  of  system 
sensitive  programs  or  data. 

Misuse  -  Unusual  resource  usage  may  be  an  indicator  of 
many  things.  It  can  certainly  increase  suspicion  that  the  user  is  a 
masquerader.  Abnormal  resource  usage  can  also  indicate  that  a 
valid  userisengaged  in  some  undesirable  activity.  For  instance. 


RLilaBase  Structure 

In  the  discussion  to  in  ■  point,  the  phrase  ‘taiso  suspicion' 
In's  been  used  without  leleronve  to  exactly  wlial  is  meant.  Most 
of  the  rules  in  the  MIDAS  system  ate  sensory  rules.  Sensory 
rules  detect  anomalous  activity  and  assert  a  conclusion  into  the 
knowledge  base  representing  the  suspected  problem.  These 
rules  may  also  issue  a  warning  message.  Another  caicgoiy  of 
mles,  referred  to  as  secondary  rules,  operate  only  on  the  output 
ol  the  sensory  mles.  These  i  uie  s  act  like  AND  gales;  tiling  only 
when  coi nun  kind- of  suspic ions  has  e  been  unur-al. 

Tigure  b  represents  the  sttueturc  ot  the  MIDAS  mlo  base. 
Each  area  of  concern  (bioakm.  masquerading,  misuse,  etc.)  is 
addtessed  by  a  different  set  of  rules.  The  output  of  these  rules 
feed  the  sceondniy  roles,  which  m  turn  i  exult  tit  cone  tele  actions 
ivmg  taken 

ACTION 


KNOWLEDGE  BASE  /  AUDIT  DATA 


Figure  6  MIDAS  Rule  Base  Structure 
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MIDAS  Operation 


MIDAS  operates  continuously,  constantly  monitoring  user 
activity  and  the  state  of  the  target  system.  If  it  detects  anomalies 
in  system  operation,  relevant  messages  are  displayed  on  the 
MIDAS  console.  The  operator  may  choose  to  act  directly  on 
these  warning  messages,  or  to  investigate  further  using  the  com¬ 
mands  available  through  the  user  interface.  For  example,  the 
operator  may  query  the  target  system  status,  or  a  user's  status,  or 
trace  specific  user  activity.  Based  on  this  analysis,  the  operator 
will  initiate  corrective  action. 

As  discussed  previously,  MIDAS  is  composed  of  a  number 
of  distinct  parts.  First  among  these  is  the  preprocessor,  imple¬ 
mented  on  Dockmaster,  which  extracts  and  reformats  relevant 
audit  data.  This  data  is  then  transferred  to  the  MIDAS  worksta¬ 
tion,  where  it  is  asserted  into  the  expert  system  shell  (P-BEST) 
and  applied  to  the  compiled  MIDAS  rules  and  statistical  sub¬ 
routines.  Any  anomalies  detected  are  reported  immediately  via 
the  MIDAS  user  interface. 

The  logic  of  the  MIDAS  rule  base  is  covered  in  the  Architec¬ 
ture  section  of  this  papier.  More  detailed  discussions  of  audit  data 
preprocessing  and  the  user  interface  are  now  presented  to 
provide  a  complete  system  description. 


The  MIDAS  system  acts  primarily  upon  five  types  of  audit 
data:  logins,  logouts,  commands,  detected  errors,  and  I/O  re- 
q  uests.  This  data  is  extracted  from  the  Dockmaster  audit  logs  and 
reformatted  into  a  time-sorted  series  of  assertions  having  the 
basic  structure  suggested  by  Denning  [2|: 

(<subject><object><action><exception>  <time- 
stamp>) 

For  most  of  the  different  audit  assertion  types,  <subjeet>  is 
list  composed  of  userid,  project,  tag,  process  identifier,  terminal 
type,  connection  source  (local  dial,  TYMNET,  or  MILNET  in¬ 
dicator),  and  hosi  id. 

Similarly,  <timc-stamp>  is  universally  formatted  as  a  list 
containing  the  elements:  absolute  time  (the  number  of  seconds 
since  midnight),  date  ( YY/MM/DD),  and  time  (HH:MM:SS) 

The  remaining  fields  <object>,  <action>,  and  <exception> 
have  varying  meanings  depending  on  the  audit  assertion  type, 
For  example,  a  typical  login  entry  might  look  something  like 
this: 

(LOGIN  (COLOSSUS  FORBIN  A  03452  HIS  VT1 
450)  NIL  NIL  NIL  (120  02/1 2/88  00:02:00)) 

and  a  command  usage  entry  might  look  like  this: 

(CMD  (COLOSSUS  FORBIN  A  03452)  NIL 
BOUND_INFO$WHO  0.2  (230  02/12/88  00:03:50)) 


User  .interface 

The  MIDAS  User  Interface  is  a  comprehensive  window- 
based  environment  composed  of  a  bit-mapped  display  which 
presents  four  panes  ananged  within  oneoveralldisplay  window, 
and  allows  various  operator  interactions  through  a  mouse  menu 
interface.  The  fourdisplay  panes  are:  the  User  Pane,  which  dis¬ 
plays  a  list  of  users  currently  on  the  system;  the  Command  Pane 


which  provides  a  mouse/menu  driven  access  to  a  number  of 
MIDAS  commands;  the  Warning  Pane,  which  displays  specific 
warning  messages  generated  by  MIDAS;  and  the  Graphical 
SystemStatus  Pane, which  is  used  to  display  the  state  of  MIDAS 
and  the  targetted  host.  The  operator  can  adjust  the  operation  of 
MIDAS,  and  triggersome  specific  report  generation  through  the 
user  interface.  (Figure  7  illustrates  the  MIDAS  window  dis¬ 
play).  The  MIDAS  user  interface  displays  the  ongoing  analysis 
of  the  target  system  security  state. 

User  Pane  -  Information  provided  in  the  MIDAS  User  Pane 
consists  of  the  Login  Time,  Userid,  Project,  and  Tag  for  all 
processes  in  the  monitored  computer  system.  (Tag  is  a  one 
character  flag  which  indicates  whether  the  user  is  in  interactive 
mode  ("a"),  or  batch  mode  Cm")). 

Two  flags  may  appear  prior  to  the  user’s  name  in  the  User 
Pane'. 

•  The  first  flag,  a  question  mark  (?),  indicates  that  the  user 
is  suspected  of  anomalous  activity.  This  suspicion  may  be 
generated  as  a  result  of  the  user’s  having  triggered  some 
combination  of  MIDAS  rules,  or  by  independent  observa¬ 
tion  by  the  Dockmaster  operator. 

•  The  second  flagwhich  may  appear  to  the  left  of  a  user  name 
is  a  capital  M.  This  mark  indicates  that  a  user’s  session  is 
now  being  closely  monitored.  All  audit  data  pertaining  to 
this  user  is  now  also  reflected  in  the  MIDAS  Warning 
Pane.  This  is  a  powerful  tool  for  de:  il.ed  user  monitoring. 

Warning  Pane  -  The  Warning  Pane  displays  the  warning 
messages  and  MIDAS  conclusions  generated  as  a  result  of 
MIDAS  lule  execution.  These  messages  include  warnings  about 
breakins,  masqueraders,  penetrations,  misuse,  trojan 
horse/virus  detection,  and  the  reasons  why  these  warnings  were 
generated. 


Sample  Messages 


NOTE:  FIRST  LOGIN  FOR  USER  COLOSSUS 
(SRC:  VT1.0438) 

MONITOR:  COLOSSUS  EXECUTED  CMD  “LIST”, 
CPU  .03 

WARNING:  FEY  EXCEEDED  1ST  THRESHOLD 
FOR  CPU  USE 

ALERT:  COLOSSUS  IS  A  MASQUERADER. 

REASONING  IS: 

LOGGED  IN  FROM  AN  UNUSUAL  SOURCE 
(3106,4452) 

LOGGED  IN  AT  UNUSUAL  TIME  (01 :45) 

EXCEEDED  1ST  THRESHOLD  FOR  CMD  ERRORS 

(15) 

EXCEEDED  2ND  THRESHOLD  FOR  SYSERRS  78 

EXECUTED  THE  INVALID  COMMANDS  ’’PRIV”, 
“SUID" 

Warning  Pane  information  is  generated  independent  of  the 
MIDAS  Window  Interface,  and  thus  can  be  made  available  on 
other  (non-windowing)  versions  of  MIDAS.  Warning  Pane 
messages  are  hierarchically  grouped  into  classes  of  related  mes¬ 
sages,  from  notes,  to  warnings,  to  system  alerts,  Each  of  these 
message  types  has  a  slightly  different  format  or  font  In  order  that 
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Hjuss  a  User:  JOIIC'" . VERIFY .  0 

User  JOHNS' s  se«Mn»  on  project  VIKiFY  is  now  bc<n>j  nonUgred. 
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User  DSGIBSQfl’s  s**-*ion  o»i  i^roj'jcl  VEkWlRRI  is  now  bu'ng  nonitoreri. 

HIDflS: 
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DSGIOffiN  kypeo  i>  .  it  14:04.  Session  duration  3, 16066?  mins ,  CPU  20.033993  sees 
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Figure  7  MIDAS  User  Interface 


the  message  typo  be  easily  distinguishable,  and  in  ordcrtliat  the 
really  important  messages  are  easily  noted.  All  messages,  front 
the  notes  to  the  system  alerts,  are  written  to  a  daily  log  along  with 
an  analysis  of  each  suspicious  user’s  session  (sec  Figure  8  for  a 
sample  session  analysis).  This  log  is  printed  at  the  end  of  the  day 
(midnight). 


(  'omnuinit  Pane  -  The  MIDAS  operator  has  available  a 
number  of  commands  to  modify  the  operating  parameters  of  the 
system  or  generate  different  displays.  MIDAS  commands  are 
invoked  by  pointing  the  mouse  at  the  desired  command  (in  the 
( 'nmmaml  Paw),  and  clicking.  Most  of  the  commands  listed  in¬ 
voke  menus  which  are  in  themselves  lists  of  commands.  These 
commands  provide  the  means  to  display  user  and  system  statis¬ 
tics.  generate  reports,  modify  MIDAS  execution  parameters, 
and  execute  operator  commands.  For  example  information 
about  a  selected  user  (selected  by  invoking  the  "Investigate  Stats 
Menu"  then  selecting  the  “Analyze  User  Session"  command  and 
mousing  on  a  current  user  in  the  User  Pane)  might  look  some 
thing  like  this: 

ACTIVITY  FOR  USER  COLOSSUS  IS 
ANOMALOUS: 

LOGGED  IN  FROM  AN  UNUSUAL  SOURCE 
LOGGED  IN  AT  AN  UNUSUAL  TIME 
USE  OF  COMMAND(S)  "PRINT",  "WHO"  IS  HIGH 
USE  OF  COMMAND(S)  “LIST"  IS  VERY  HIGH 
OCCURRENCE  OF  COMMAND  ERRORS  IS  HIGH 
OCCURRENCE  OF  SYSERRS  IS  VERY  HIGH 
COLOSSUS  IS  A  SUSPECTED  MASQUERADER 


Figure  8  User  Session  Analysis 


Graphical  System  Status _Ftui£  -  This  pane  (the  low  right 
comer  of  figurc7)displays  information  about  the  stateol  thet  ,r- 
get  host,  and  about  the  state  of  MIDAS.  Currently  four  his¬ 
tograms  and  three  meters  are  displayed.  The  histogram  labelled 
"MIDAS  Concern  Levels"  displays  how  many  facts  the  expert 
system  has  concluded  in  these  areas  (attempted  breakins. 
masquerader,  etc.).  The  three  histograms  labelled  "Logins", 
"Total  CPU",  and  "Total  Syscrrs"  inform  the  operator  about 
these  particular  occurences.  Aquick  glance  at  these  histograms 
can  reveal  how  many  of  these  occurrences  have  occurred  today 
(or  in  any  particular  hour  of  today)  as  well  as  how  many  occur 
system  wide  per  day.  Finally,  across  the  bottom  of  this  pane, 
three  meters  give  the  operator  some  indication  as  to  how  well  the 
expert  system  is  running.  The  MIDAS  RPM  meter  informs  the 
operator  how  many  audit  records  per  minute  the  expert  system 
processes.  The  MIDAS  FPM  meter,  describes  how  many  facts 
theexpert  system  processes.  Finally  the  MIDAS  Facts  meter  in¬ 
forms  the  user  how  many  facts  are  left  in  the  fact  base. 

Results 


MIDAS  tracks  all  user  activity  on  Dockniastcr  in  real-time. 
I  lowever.  in  order  to  implement  the  system  in  a  mod  ular  fashion 
and  test  in  a  controlled  environment,  MIDAS  was  initially 
deployed  on  only  HU  users,  approximately  1 1%  of  the  total  user 
population.  Data  was  transferred  daily  via  magnetic  tape.  Con¬ 
sequently.  the  system  was  tested  by  flooding  it  with  audit  entries 
in  simulated  real-time. 

MIDAS  performed  as  intended  in  the  test-bed  implementa¬ 
tion.  Under  limited  testing  of  crude  simulated  attacks,  almost  all 
anomalous  activities  were  detected.  For  example,  rest  data 
developed  by  changing  the  userid  throughout  one  session’s  set 
of  audit  data  to  the  userid  of  another  system  user  resulted  in  the 
determination  by  MIDAS  that  the  test  user  was  a  masquerader. 
In  addition,  a  number  of  unexpected  anomalies  were  detected  in 
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"live"  audit  data  that  arc  now  under  further  review.  MIDAS 
reliably  flags  a  monitored  set  of  17  different  immediate  attack 
activities  (For example  attempting  to  use  sensitive  system  com¬ 
mands).  Those  rules  which  fire  based  on  overall  system  state 
anomalies  are  also  quite  reliable. 

Despite  the  limited  size  of  the  test-bed,  we  became  confi¬ 
dent  that  MIDAS  would  be  capable  of  monitoring  the  complete 
DOCKMASTFR  user  base.  We  gained  confidence  because 
MIDAS  was  deliberately  designed  with  speed  as  a  paramount 
criteria,  and  because  initial  test  data  timings  were  very 
favorable. 

MIDAS  is  fast  for  three  reasons.  First,  MIDAS  rules  arc 
compiled  into  lispobjcc|  eude,  not  interpreted  as  isthccaseusing 
many  expert  system  sin  I  Is.  Second,  wherever  possible,  MIDAS 
titles  have  been  gem. utilized  to  handle  as  many  at  eas  of  concern 
as  possible.  Minimizing  the  number  of  rules  within  the  system 
in  turn  minimizes  the  number  of  rule/fact  bindings  that  occur, 
thus  reducing  the  number  of  possibilities  the  system  must  check. 
Third,  we  have  placed  a  number  of  analysis  functions  into  the 
user  interface  to  be  triggered  at  the  operator  discretion,  rather 
tiiaii  in  the  rule  base  to  be  triggered  nondelcrniinisticly  by 
matching  fact  patterns.  For  example,  the  MIDAS  user  interface 
contains  a  function  for  checking  if  any  users  have  been  inactive 
for  an  excessive  period  of  time.  This  function  detects  misuse 
rather  than  intrusion,  and  does  not  need  to  be  active  constantly. 
Putting  its  execution  at  the  operator's  discretion  reduces  the  load 
on  the  rule  base. 

Actually,  MIDAS  is  faster  than  we  had  anticipated.  In 
processing  tiic  data  for  the  limited  test  group  of  1 05  users  over  a 
period  of  approximately  45  days.  MIDAS  has  averaged  an 
evaluation  rate  of 425  audit  entries  per  minute.  Theavcrage  time 
it  has  taken  to  process  an  entire  day’s  tcst-lwd  activity  is  9 
minutes,  (liven  that  the  test  population  was  1 1%  of  the  normal 
target  system  population,  a  simple  extrapolation  indicated  that 
the  system  could  process  all  audit  data  fur  an  entire  day  in  less 
than  2  hours,  liven  allowing  a  massive  reduction  in  throughput 
based  on  the  i  ule/faet  binding  complexities  that  would  accumu¬ 
late  during  peak  periods  of  Dock-master  usage  (30  -  50  users), 
MIDAS  appearred  ready  to  monitor  Dock  master  in  real-time. 

Currently  me  system  runs  in  real  time.  The  system  appears 
slightly  oversensitive.  Rules  based  completely  on  statistical 
profiling  often  trigger  too  readily  because  the  thresholds  of  con¬ 
cern  are  often  too  low.  This  problem  may  be  solved  by  develop¬ 
ing  belter  algorithms  for  concern  thresholds,  or  some  basic 
adjustments  to  the  rules  dealing  with  individual  user  activity 
may  he  required.  As  user  profiles  become  normalized,  the  sys¬ 
tem  wiil  belterdilTereniiate  between  suspicious  and  normal  user 
activity.  MIDAS  has  been  successful  in  profiling  system-wide 
behavior,  by  summarizing  from  the  logs  such  statistics  as  total 
login  failures,  total  system  errors,  etc...  As  it  stands,  the  system 
litis  dctec  led  many  anomalies,  some  of  a  suspicious  nature.  We 
will  continue  investigation  of  these  unusual  activities  with  (lie 
help  of  the  system  administration  personnel.  Although  the  sys¬ 
tem  is  still  being  enhanced  and  tested,  we  believe  that  applying 
MIDAS  to  the  audit  log  problem  improves  detection  of  com 
puier  abuse  and  misuse. 


MIDAS  was  designed  specifically  to  provide  intrusion 
detection  for  the  National  Computer  Security  Center’s 
i  loneywcll  Mullies  system.  However,  MIDAS  could  easily  be 
generalized  to  monitor  any  Muitics  system.  With  someeffort.it 
may  be  operable  fora  number  of  different  target  systems.  For 


example,  MIDAS  may  soon  be  modified  to  monitor  an  IBM  sys¬ 
tem  running  ACF2.  Also,  although  the  MIDAS  expert  system 
wasdeveloped  on  a  Symbolics  workstation,  the  basic  system  has 
been  ported  to  a  Sun  workstation.  Efforts  are  ongoing  todevelop 
a  user  interface  for  the  Sun  version  which  takes  advantageof  Sun 
capabilities  for  graphics  and  color  display, 

A  proposed  enhancement  is  to  implement  Markovian 
analysis  of  command  input  patterns.  Under  Markovian  analysis, 
cadi  command  type  is  regarded  as  a  state  variable,  and  a  state 
transition  matrix  is  used  to  characterize  the  transition  frequen¬ 
cies  between  states.  A  command  input  transition  would  be  ab¬ 
normal  if  its  probability  (as  determined  by  the  previous  system 
state  and  the  current  transition  matrix  entry)  was  too  low.  This 
mechanism  can  be  used,  for  example,  to  determine  if  the  com¬ 
mand  sequences  of  a  user  are  simi  lar  to  those  which  characterize 
a  penetrator, 

Some  means  for  validating  the  performance  of  the  rule  base 
should  he  developed.  Interim  measures  include  the  analysis  of 
MIDAS  performance  under  normal  conditions  and  under 
‘stress  ’  conditions.  These  stress  conditions  will  be  generated  by 
assembling  a  tiger  team  to  attempt  to  com  omisc  the  monitored 
system.  1  lowevcr,  a  more  rigorous  melh  for  rule  base  valida¬ 
tion  and  verification  is  greatly  needed.  This  represents  acurrcnt 
area  of  particular  concern  in  artificial  intelligence.  Numerous 
approaches  have  been  proposed  for  analyzing  the  structure  of 
rule-based  systems  to  check  for  consistency  and  completeness 
(see  [5, 6,7, 1 OJ).  Tools  of  litis  nature  arc  presently  under  con  ¬ 
sideration  as  extensions  for  the  Production-Based  Expert  Sys¬ 
tem  Toolset  which  supports  MIDAS. 

The  rules  of  the  expert  system  could  be  improved  by  inter¬ 
viewing  hackers,  and  those  who  have  caught  hackers.  Current¬ 
ly  titc  heuristics  of  the  expert  system  rules  are  based  on  the 
knowledge  of  system  administrators  and  system  programmers. 
Also,  knowledge  gained  from  discovering  intrusion,  misuse, 
penetration,  etc...  will  further  refine  and  enhance  the  rules, 
Finally,  we  would  like  to  enhance  MIDAS  so  dial  if  the  sys¬ 
tem  runs  unattended,  MIDAS  can  act  on  its  own  suspicions. 
That  is,  the  system  could  take  the  least  disruptive  action  to  fol¬ 
low  upon  ilsconclusions.  Thiscouldoccurasaresultofauser’s 
fail  tire  to  correctly  answer  a  challenge  response  question  issued 
by  MIDAS  in  reponse  to  the  user’s  previous  anomalous  session 
activity  |  M  |.  We  want  to  enhance  MIDAS  so  that  it  can  interact 
with  the  target  host  if  it  must.  This  would  broaden  its  scope  con¬ 
siderably  from  that  of  just  an  audit  reduction  tool. 
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Auditing  in  a  Distributed  System:  SunOS  MLS  Audit  Trails 
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ABSTRACT 

This  paper  describes  ihc  important  features  of  die  SunOS  MLS  auditing  mechanism,  and  how  it  solves  the 
problems  of  performing  useful  audit  functions  in  large  distributed  systems.  The  goals  and  experiences  which  led  to 
■  this  design  are  described.  The  SunOS  MLS  mechanism  is  compared  with  other  implementations. 


INTRODUCTION 

This  paper  begins  with  a  brief  overview  of  the  SunOS  MLS  system: 
its  hardware,  its  software  interface,  and  its  additional  security 
features.  That  overview  server,  merely  to  introduce  the  system; 
some  familiarity  with  UNIX  and  the  Trusted  Computer  System 
Evaluation  Criteria  [DoD851  is  expected  for  complete  understand¬ 
ing  of  this  paper. 

The  system  overview  is  followed  by  three  sections  describing  the 
characteristics  that  distinguish  auditing  in  SunOS  MLS  from  more 
conventional  implementations.  The  section  on  audit  message  life 
cycle  describes  how  an  audit  message  travels  from  its  point  of  ori¬ 
gin  to  permanent  storage,  This  mechanism  was  designed  to  minim¬ 
ize  overhead  for  message  generation  while  still  strictly  limiting  die 
amount  of  audit  data  lost  due  to  u  system  failure.  That  section  also 
describes  the  methods  the  administrator  can  use  to  manage  large 
volumes  of  online  audit  data,  and  how  the  data  can  be  migrated 
offline. 

The  section  on  audit  analysis  describes  the  audit  analysis  tool, 
which  is  how  the  "single  system  image"  of  SunOS  MLS  is  imple¬ 
mented  for  auditing.  Tills  tool  has  extensive  merging  and  selection 
capabilities,  and  is  die  primary  mechanism  for  processing  audit 
data  before  analysis  or  display. 

The  section  on  audit  message  format  summarizes  the  "Flexible 
Audit  Mcssag,  Format",  which  was  designed  as  a  system- 
indcjxmdont  format  suitable  for  use  in  arbitrary  operating  systems, 
not  just  SunOS  MLS.  This  format  is  being  considered  by  die  IEEE 
P  1003.6  and  X/Open  standards  subcommittees  on  security. 


UNIX  is  a  registered  trademark  of  AT&T.  Ethernet  it  a  registered  trademark  of  Xerox 
Corporation.  Sun  Microsyttcme  is  a  registered  trademark  of  Sun  Microsystems,  Inc. 
SunOS,  NT'S,  Sun-3.  Sun-4,  and  Sun  View  arc  trademarks  of  Sun  Microsystems,  Inc. 
POSJX  is  a  trademark  of  the  Initnute  of  Electrical  and  Electronic  Engineers.  XyOpen 
is  t  registered  trademark  of  the  X/Opcn  Company,  Lid. 

'I "He  work  deaenbed  herein  was  performed  under  contract  to  Sun  Microaystems.  Inc. 

The  statistics  and  mcchanisma  presented  in  this  paper  ire  taken  from  a  pre-rclca-c 
version  of  SunOS  MI.S,  and  do  not  reprecant  •  commitment  to  any  specific 
Implementation  or  performance  characteristics  of  the  actual  SunOS  MI^S  product. 


The  paper  ends  with  a  section  describing  the  implementation 
characteristics  of  SunOS  MLS  auditing.  This  includes  some  com¬ 
parisons  between  SunOS  MLS  and  other  systems  ([Piccioto87], 
[Gligor86]),  as  well  as  a  preliminary  discussion  of  SunOS  MLS 
auditing  performance. 


OVERVIEW:  WHAT  IS  SunOS  MLS? 

Sun’s  SunOS  MLS  product  is  secure  distributed  system  which  is 
targeted  lor  evaluation  at  the  B1  Criteria  level  and  which  is 
currently  undergoing  developmental  evaluation  with  the  NCSC  It 
is  a  variant  of  Sun’s  standard  SunOS  system  (release  4.0)  with 
which  it  has  complete  application  compatibility  except  in  areas 
where  security  requirements  prohibit.  SunOS  MLS  runs  on  Sun’s 
Sun-3  and  Suu-4  hurdwarc  product  line,  which  ranges  from 
1.5  MIPS  desktop  workstations  through  10  MIPS  workstations  and 
file  server  machines.  It  has  been  under  development  since  mid- 
1986,  and  is  described  in  more  detail  by  [Sun87]. 

SunOS  is  a  version  of  the  UNIX  operating  system  which  includes 
compatibility  with  the  AT&T  System  V,  Release  3  definition, 
numerous  enhancements  from  the  Berkeley  4.2/4.3bsd  systems,  and 
Sun’s  own  extensions.  In  addition  to  the  basic  UNIX  functions, 
SunOS  includes  SunVicw.  a  window-based  user  interface,  and  full 
support  for  the  TCP/IP  and  NFS  (Network  File  System)  network 
protocols. 

SunOS  MLS  is  an  extended  version  of  the  basic  SunOS  system 
intended  to  meet  die  B 1  class  requirements  of  die  Trusted  Com¬ 
puter  System  Evaluation  Criteria  (TCSEC)  [DoD85),  In  addition  to 
auditing,  wluch  this  paper  describes,  it  includes  protection  of  user 
passwords,  support  of  mandatory  security  labels  in  the  file  system 
and  in  NFS,  device  labeling,  mandatory  security  for  socket-based 
interprocess  communication,  and  an  extension  to  die  window  inter¬ 
face,  Secure  SunView,  which  places  mandatory  access  control 
labels  on  all  on-screen  windows  and  allows  simultaneous  display 
and  manipulation  of  data  at  many  different  labels.  A  more  com¬ 
plete  description  is  found  in  [Sun87], 
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SunOS  MLS  Configuration 

A  SunOS  MLS  system  is  a  distributed  system  comprising  one  or 
more  physical  machines  (such  as  workstations  or  die  servers)  con¬ 
nected  to  a  dedicated  Local  Area  Network  (LAN).  Because  the 
LAN  (which  uses  Ethernet-based  technology)  represents  the  com¬ 
munication  path  between  the  CPUs  in  the  distributed  system,  it  is 
also  referred  to  as  the  interconnect  or  “backplane"  for  the  system. 
Some  machines  may  be  referred  to  as  “servers",  generally  because 
their  primary  purpose  is  to  export  disk  storage  to  other  machines. 
In  a  typical  configuration,  most  machines  are  “diskless"  and  use 
NFS  to  reference  their  data,  which  is  stored  on  one  or  more  servers. 

Because  all  the  machines,  their  peripherals  (if  any)  and  the  LAN 
interconnect,  are  part  of  the  same  system  and  equally  crusted,  phy¬ 
sical  security  is  required  for  all  those  components  to  ensure  that  no 
compromise  occurs  due  to  violation  of  hardware  integrity.  In  a 
fully  secure  configuration,  no  ‘  ‘foreign’  ’  hardware  may  be  attached 
to  the  LAN:  it  is  used  only  for  communication  among  a  set  of 
machines  all  running  the  same  TCB  software. 

Single  System  Image 

Although  each  machine  in  a  SunOS  MLS  system  is  a  partly 
independent  processor  running  its  own  instance  of  die  TCB  and  its 
own  set  of  users,  the  entire  set  operates  as  a  single  system.  This  is 
possible  because  a  user's  (and  administrator's)  view  of  the  system 
is  independent  of  die  machine  being  used.  Ail  machines  share  the 
same  file  system,  and  a  file  name  has  the  same  meaning  regardless 
of  location. 

Similarly,  all  administrative  functions  may  be  performed  (by  an 
appropriately  authorized  user)  from  any  machine.  The  administra¬ 
tive  databases  axe  all  maintained  at  a  single  point,  and  distributed 
throughout  the  system  by  Sun’s  Yellow  Pages  distributed  database 
mechanism.  In  particular,  this  is  true  of  authentication  data,  so  dial 
user  identity  is  unique  regardless  of  location. 

As  is  described  below,  this  single  system  image  is  very  important 
for  auditing.  This  concept  allows  die  system  administrator  to  view 
and  analyze  die  audit  trail  for  the  entire  system  as  a  single  entity, 
even  though  the  audit  data  was  generated  by  numerous  independent 
machines  and  may  be  stored  in  multiple  locations.  Because  file 
names  and  user  identities  are  unique  dirough  the  system,  it  is 
straightforward  to  analyze  the  merged  audit  data. 

Accountability 

An  important  aspect  of  SunOS  MLS  for  auditing  is  the  audit  user 
ID.  This  is  a  unique  user  identity,  kept  in  addition  to  the  standard 
UNIX  real  user  ID  and  effective  user  ID  values,  that  identifies  a 
process  (subject).  The  audit  user  ID  is  assigned  to  a  process  only 
by  its  initial  login  through  the  trusted  patlt,  and  its  value  is  the  same 
as  the  initial  values  of  tite  other  user  IDs.  This  identity  is  inherited 
by  all  descendants  of  the  initial  process,  and,  in  effect,  provides 
accountability  back  to  the  user  whose  fingers  are  at  the  keyboard. 
Unlike  the  effective  user  ID  and  real  user  ID,  the  audit  user  ID’s 
value  is  never  changed.  All  activities  performed  between  login  ind 
logout,  regardless  of  which  window  they  are  performed  in,  or 


which  machine  the  process  runs  on,  are  accountable  to  the  original 
logged  in  user.  For  example,  the  audit  user  ID  is  maintained  when 
the  user  issues  the  su  command  to  switch  to  a  privileged  role  or 
uses  the  rlogin  command  to  initiate  a  session  on.  another  machine. 


AUDIT  MESSAGE  LIFE  CYCLE 

The  generation  side  of  the  audit  mechanism  is  responsible  for 
responding  to  "audit"  calls  from  TCB  programs,  generating  mes¬ 
sages,  and  writing  those  messages  to  permanent  storage  for 
analysis.  Although  this  is  a  conceptually  simple  path,  the  require¬ 
ments  for  high  bandwidth  and  reliable  transmission  often  make  this 
a  complex  process.  Even  in  a  conventional  multi-user  timesharing 
system,  the  path  for  an  individual  audit  message  may  include 
several  buffers,  each  perhaps  slower  to  accesis.  but  less  likely  to 
overflow.  In  a  distributed  system,  where  audit  message  storage 
may  be  accessed  through  a  communication  interface,  the  problems 
are  exacerbated. 

Audit  Message  Pre-Selection 

The  first  part  of  an  audit  message's  life  is  really  the  decision  of 
whether  to  generate  the  message  at  all.  The  TCSEC  requires  not 
that  all  security-relevant  events  be  audited,  but  merely  that  they  be 
auditable.  It  also  specifies  a  minimum  set  of  characteristics  for 
selecting1  specific  audit  messages.  This  allows  the  administrator 
some  flexibility  in  making  the  tradeoff  between  what  to  collect  and 
the  volume  of  information  recorded.  These  administrative  control 
mechanisms  will  probably  be  different  in  different  systems,  but 
they  always  rely  on  some  form  of  categorization  of  messages. 

Although  the  most  powerful  selection  mechanisms  are  available 
only  at  analysis  lime,  some  limited  options  are  available  to  control 
the  set  of  messages  recorded.  For  each  user,  the  system  administra¬ 
tor  may  specify  a  set  of  audit  event  classes  for  which  messages 
should  be  recorded.  These  are  further  divided  into  two  sets:  mes¬ 
sages  to  be  recorded  when  an  attempted  operation  is  successful,  and 
messages  to  be  recorded  when  an  attempted  operation  fails  for  any 
reason.  These  per-user  values  actually  just  modify  a  system-wide 
default;  rather  than  specifying  the  exact  set  of  classes  for  each  user, 
the  administrator  writes  specifications  such  as  "the  default,  plus 
successful  access  changes,  plus  all  failed  attempts".  Thus,  the 
administrator  can  establish  a  set  of  audit  classes  for  the  whole  sys¬ 
tem,  and  adjust  it  individually  for  particularly  trustworthy  or  partic¬ 
ularly  suspicious  users. 

The  class  selection  mechanism  is  based  on  audit  message  types  (see 
AUDIT  MESSAGE  FORMAT,  below).  Every  distinct  operation 
generates  a  message  of  a  different  type.  One  set  of  message  types 
is  defined  to  describe  each  of  the  operations  defined  in  the  POSIX 
specification,  and  individual  systems  (such  as  SunOS  MLS)  define 


1  Th*  TCSEC  allows  evantf  to  b*  "lalecUvely  audit*!"  either  by  malting  the 
aalection  at  generation  lima  (pca-ealection),  or  by  licking  tpeclflc  tnaeiager  out  of  the 
audit  trail  it  analyaia  lima  (poat-ealactlon).  SunOS  MLS  providaa  aalactlon  by  uaer 
identity  (and  maaaaga  claae)  at  both  ganantion  and  analyaia  lima,  but  only  providaa 
aalactlon  by  object  tocurity  label  (and  moat  other  lUiibutea}  a!  analyaia  lima. 
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additional  message  types  tor  their  extensions.  Additional  message 
types  can  also  be  defined  by  third-party  applications.  The  number 
of  types  may  be  quite  large:  in  SunOS  MLS,  it  is  approximately 
300.  The  message  type  is  a  fine  . grained  selection  mechanism,  and 
corresponds  directly  to  the  operation  performed  by  an  administrator 
or  a  user  program. 

There  is  a  system-wide  table  that  maps  each  of  these  individual 
message  types  into  one  of  a  small  number  of  message  classes.  The 
message  class  indicates  the  class  of  operations  (such  as  “adminis¬ 
trator  action”,  “file  modification",  etc.)  to  which  the  message 
belongs.  Message  classes  are  used  to  identify  subsets  of  the  com¬ 
plete  audit  trail  which  arc  to  be  recorded  for  particular  users  or  pro¬ 
grams  (thus  reducing  tire  volume  of  data).  Since  message  classes 
arc  intended  for  administrative  control  of  the  audit  mechanism, 
there  should  be  only  a  fairly  small  number  defined.  It  is  expected 
that  the  set  of  classes  may  be  different  in  different  system  imple¬ 
mentations;  in  SunOS  MLS,  13  classes  arc  currently  defined. 

Audit  Messages  in  the  Kernel 

A  SunOS  MLS  audit  message  starts  life  in  the  kernel  (the  hardware 
privileged  part  of  the  TCB  software).  It  may  have  been  generated 
either  by  an  auditing  call  internal  to  the  kernel,  or  by  a  system  call 
made  from  some  trusted  process.  In  either  case,  the  information  for 
the  audit  message  is  gathered  up  and  formatted  into  an  audit  mes¬ 
sage  data  structure,  which  is  then  stored  in  one  of  a  small  set  of 
buffers  in  kernel  memory.  II  a  failure  occurs  in  the  local  macliinc, 
no  more  than  those  buffers  worth  of  audit  data  can  be  lost  (up  to  10 
audit  messages).  Once  a  message  is  placed  in  a  buffer,  the  “audit 
daemon"  is  notified. 

The  Audit  Daemon 

The  audit  daemon  is  an  independent  process  which  runs  on  each 
machine.  Unlike  ordinary  processes,  it  runs  almost  entirely  in  ker¬ 
nel  mode.  Therefore,  except  when  handling  errors,  ull  the  data  it 
manipulates  is  in  kernel  memory,  and  not  subject  to  swapping  or 
paging.  This  allows  the  audit  daemon  to  respond  very  quickly  to 
arriving  audit  messages  and  ensures  that  it  is  not  a  bottleneck. 

The  audit  daemon’s  job  is  to  take  the  audit  messages  frem  their 
kernel  buffers  and  write  them  to  the  destination  file.  In  normal 
operation,  die  audit  daemon  is  awakened  whenever  a  message  is 
placed  in  a  kernel  buffer.  It  runs  promptly  and  [lerforms  a  normal 
file  system  write  operation  to  write  out  the  message.  This  process 
is  regaled  until  all  the  kernel  buffers  are  again  empty,  at  which 
point  the  audit  daemon  goes  back  to  sleep  and  awaits  another  mes¬ 
sage.  The  audit  daemon  runs  in  kernel  mode  to  avoid  an  extra 
buffering  step  and  to  improve  context  switch  efficiency.  Its  pro¬ 
cessing  loop  is  invoked  by  a  special  system  call  which  never 
returns  from  the  kernel  unless  an  error  occurs, 

In  addition  to  this  normal  mode  of  operation,  the  audit  daemon  is 
also  responsible  for  creating  audit  files,  for  handling  any  errors 
which  occur  while  writing  to  an  audit  file,  and  for  monitoring  the 
amount  nf  space  still  available  for  writing  more  messages.  When¬ 
ever  an  I/O  error  or  a  file  system  full  condition  occurs,  the  audit 
daemon  returns  to  user  mode,  selects  a  new  location  for  audit  data. 


and  creates  a  new  file  into  which  messages  will  be  written.  It  then 
again  invokes  its  special  system  call  to  write  messages  to  this  new 
file.  No  messages  are  lost  on  the  local  machine  when  this  occurs, 
since  the  kernel  buffers  remain  full  while  waiting  for  the  audit  dae¬ 
mon  to  find  a  new  home  for  them. 

Each  audit  daemon  has  a  list  of  directories  (known  as  "audit  file 
systems")  from  which  it  can  choose  a  location  for  audit  files.  It 
consults  this  list  whenever  a  new  audit  file  must  be  created.  Typi¬ 
cally,  this  list  is  different  for  each  machine  or  small  group  of 
machines,  in  order  to  spread  the  audit  traffic  evenly.  Normally,  the 
directory  is  chosen  based  on  a  fixed  algorithm,  but  the  audit  dae¬ 
mon  also  has  a  control  interface  that  allows  an  administrator  to 
direct  its  attention  to  a  particular  audit  file  system,  or  simply  to 
close  out  the  current  audit  file  and  open  a  new  one. 

When  the  audit  daemon  is  unable  to  find  a  destination  for  the  audit 
messages,  or  if  the  audit  daemon  itself  suffers  a  failure,  the  kernel 
buffers  continue  to  fill  up.  As  soon  as  all  10  kernel  buffers  are  in 
use,  the  machine  ceases  to  perform  any  auditable  operations  until 
the  condition  is  remedied  or  until  it  is  rebooted.  The  audit 
daemon's  operations  while  trying  to  create  new  audit  files  arc  not 
audited  until  after  a  new  audit  file  is  available,  to  avoid  an  infinite 
loop.  Because  the  audit  daemon  keeps  trying  to  create  new  audit 
files,  as  soon  as  the  error  condition  is  remedied,  it  will  succeed, 
drain  the  kernel  buffers,  and  the  processes  on  the  machine  which 
arc  being  audited  (and  therefore  were  hanging,  awaiting  kernel 
buffers)  will  resume  normal  operation. 

litis  recovery  mechanism  is  im)x>rlant  because  of  the  distributed 
nature  of  the  SunOS  MLS  system.  Because  audit  files  are  usually 
physically  resident  on  disks  attached  to  remote  machines,  the  audit 
daemon  references  them  using  the  NFS  protocol  over  die  LAN 
interconnect.  The  failure  or  temporary  unavailability  of  one  of 
diesc  remote  machines  should  not  halt  the  entire  system. 

Audit  File  Systems 

Audit  files  are  typically  kept  in  dedicated  file  systems2  reserved  for 
audit  data  alone.  This  is  done  to  keep  the  audit  data  from  interfer¬ 
ing  with  other  user  and  system  files;  if  an  audit  file  system  becomes 
full,  the  effect  is  only  u>  direct  audit  messages  to  another  location, 
radier  than  llic  more  serious  effects  of  exhausting  disk  storage  used 
for  odier  purposes. 

Audit  file  systems  arc  also  typically  kept  on  a  small  set  of  machines 
acting  as  “audit  servers",  and  referenced  through  NFS.  Tills 
allows  for  efficient  and  reliable  storage  because  the  audit  servers 
can  be  chosen  to  have  large  amounts  of  disk  storage  and  high  relia¬ 
bility.  Storing  audit  files  for  many  machines  on  a  single  server  also 
speeds  analysis,  since  those  files  can  all  be  accessed  directly  on  that 
machine,  rather  dtan  duough  NFS.  Although,  for  instance,  audit 
data  could  be  stored  on  the  local  disks  attached  to  individual  desk¬ 
top  machines,  this  would  be  inefficient  for  access,  and  would  also 
mean  that  some  audit  data  would  be  unavailable  for  analysis  simply 


3  A  SunOS  (tic  tyrtem  U  ■  fixod-bize  region  of  diik,  or  tn  entire  dirk,  which 
contain!  *  portion  of  the  ryitem'i  directory  hierarchy. 
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because  the  user  of  some  machine  turned  its  power  off.  Finally,  use 
of  audit  servers  may  improve  the  physical  security  of  audit  data. 
Although  the  TCB  prevents  users  from  accessing  any  data,  even 
that  on  local  disks,  except  as  allowed  by  the  security  policy, 
transmission  of  audit  data  to  a  remote  machine  in  a  physically  more 
protected  environment  may  still  be  desirable. 

Recovery  From  Unusable  File  Systems 

An  audit  file  system  may  become  unusable  either  because  it  is  inac¬ 
cessible  (its  server  machine  has  crashed,  or  its  network  connection 
is  broken),  or  because  it  is  full.  In  the  first  case,  after  some  brief 
attempts  at  error  recovery,  an  audit  daemon  simply  selects  the  next 
audit  file  system  from  its  list,  and  attempts  to  cteate  a  new  audit 
file. 

I 

In  the  second  case,  the  file  system  has  reached  one  of  two  limits: 
soft  or  hard.  The  soft  limit  is  a  variable  threshold  set  by  the 
administrator  which  causes  the  audit  daemon  to  run  the  audit  _warn 
eonunand  script.  After  encountering  the  soft  limit,  die  audit  dae¬ 
mon  attempts  to  switch  to  using  anodicr  audit  file  system  which  has 
not  yet  readied  its  soft  limit.  Encountering  the  hard  limit  simply 
means  that  no  space  remains,  and  that  cither  a  new  location  must  be 
found  or  llte  machine  will  hang  awaiting  space  somewhere. 

In  all  these  limit  and  error  cases,  die  audiljvarn  script  is  run.  A 
default  version  of  diis  script  is  shipped  widl  the  product.  An  instal¬ 
lation  may  modify  it  to  take  mote  complex  recovery  uclions.  The 
default  action  on  dtese  conditions  is  suiiply  to  warn  die  administra¬ 
tor  about  whatever  condition  has  arisen,  by  sending  mail,  and  by 
printing  a  message  on  die  console  for  die  more  serious  conditions. 
However,  the  script  can  be  tailored  to  perform  arbitrarily  complex 
actions  as  well,  such  as  automatically  deleting  or  moving  old  audit 
files  from  a  full  file  system,  terminating  user  processes  to  prevent 
additional  activity,  or  changing  die  audit  flags  for  exisling 
processes  to  reduce  die  set  of  events  being  audited. 

Archiving  Audit  Files 

In  addlliun  to  die  lire  audit  files  that  are  being  written  by  die  audit 
daemons,  the  administrator  must  also  manage  old  audit  data.  The 
audit  reduction  tool  provides  numerous  ways  of  doing  diis 

The  first  thing  to  do  with  audit  data  is  gcncrullv  to  combine  it  (a 
day’s  worth  at  a  time,  perhaps)  into  a  single  file  and  move  it  to 
another  file  system.  The  destination  need  nol  be  a  dedicated  audit 
file  system,  since  the  combined  file  will  nol  grow  unprcdictably 
after  it  is  created.  Often,  diis  combination  process  involves  several 
steps  and  intermediate  destinations,  but  as  long  us  die  directories 
arc  appropriately  organized,  the  rearrangements  will  t>e  transparent 
to  the  audit  analysis  tools. 

Another  form  of  archiving  is  tape.  Although  no  software  is  pro¬ 
vided  specifically  for  managing  tapes  of  audit  archives,  the  ability 
to  combine  and  trim  audit  files  makes  tape  management  much 
simpler. 

Two  other  forms  of  management  for  online  audit  files  arc  available: 
compression  and  trimming.  Compression  uses  the  standard  SunOS 


compress  program  to  reduce  the  size  of  audit  files;  the  reduction 
tool  automatically  handles  compressed  audit  data,  uncompressing 
when  reading  it,  and  generating  compressed  data  on  request. 

Finally,  audit  files  can  be  trimmed  of  unwanted  messages.  This 
allows,  for  example,  an  administrator  to  keep  a  full  year’s  worth  of 
login  and  logout  messages  online,  while  having  the  other  messages 
readily  available  in  complete  audit  files  on  tape.  The  trimming 
capability  is  also  implemented  in  the  audit  reduction  tool. 


AUDIT  DATA  ANALYSIS 

Audit  analysis  in  SunOS  MLS  is  performed  with  the  aid  of  the 
audiireduce  program.  This  is  used  to  perform  a  logical  merge  of  all 
the  audit  files  in  the  system,  select  some  messages  for  processing, 
and  output  them  as  a  stream  of  messages  for  processing.  Of  course, 
audiireduce  does  not  physically  merge  all  the  audit  files  every  time 
it  is  run  —  that  could  represent  gigabytes  of  data.  Rather,  it  selects 
messages  (by  time  and  machine  identity)  only  from  appropriate’ 
files,  and  merges  those,  trimming  out  unwanted  messages  as  early 
as  possible  in  the  merge.  In  this  way,  it  provides  the  most  efficient 
possible  presentation  of  any  desired  subset  of  the  system-wide  audit 
trail. 

No  actual  analysis  is  performed  by  audiireduce ;  rather,  its  purpose 
is  to  write  (to  sldout )  a  stream  of  messages  for  processing  by 
another  program.  The  simplest  example  is  the  praudil  program, 
which  simply  displays  the  messages  in  human-readable  form,  litis 
can  be  combined  with  grep  and  other  SunOS  ulilitics  to  make  more 
specific  selections. 

Tito  dynamic  read  mode  of  audiireduce,  rather  than  reading  mes¬ 
sages  already  present  in  audit  files,  watches  all  the  audit  files  and 
file  systems  for  new  messages  and  files,  and  writes  them  to  its  out¬ 
put  as  soon  as  they  appear.  This  output  can  then  be  piped  into  a 
program  or  even  a  simple  shell  script  to  perform  real-time  analysis 
and  alarms.  It  can  even  be  piped  into  a  real-time  alarm  shell  script; 
a  (rrogram  lias  been  developed  independently  of  the  mainstream 
SunOS  MLS  development  effort  to  take  advantage  of  this  capabil¬ 
ity:  it  dynamically  displays  the  most  common  recent  audit  mes¬ 
sages  in  a  graphical  form. 

Merging  Audit  Files 

The  merge  of  audit  files  relics  on  the  fact  that  ail  the  audit  messages 
in  a  file  are  recorded  in  lime-sorted  order.  Because  each  audit  file 
is  written  initially  by  exactly  one  process,  some  machine's  audit 
daemon,  the  daemon  can  easily  ensure  this.  Furthfermore,  the 
filenames  of  all  audit  files  contain  a  pair  of  timestamps  and 
machine  name3,  so  that  the  origin  and  times  of  audit  messages 
within  a  file  can  be  determined  by  efficient  examination  of  the  file's 


1  This  convention  is  implemented  by  the  audit  daemon  and  by  auditrtduLa  (when 
it  write*  file*),  end  is  relied  upon  by  aucUtrtd**ct  when  reading  Alee.  Audit  files  with 
other  names  are  inconvenient  to  manipulate,  and  auJitrtduca  provide*  a  function  to 
regenerate  the  timestamps.  This  is  important  for  Axing  up  Ales  which  were  not  closed 
normally  (because  of  •  crash  or  Ale  system),  and  whose  ending  timestamp  still 
indicates  "VO  in  progress”. 
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name,  rather  than  its  contents, 

Whenever  audit  data  is  generated  by  independent  processes,  and 
more  so  when  generated  on  independent  machines,  synchronization 
of  time  stamps  in  audit  messages  can  be  a  problem.  In 
SunOS  MLS,  this  is  not  a  significant  problem,  because,  in  general, 
all  of  a  particular  subject's  (process's)  auditable  activities  are 
recorded  on  the  local  machine  where  the  subject  is  running.  Some 
activities,  such  as  remote  login,  may  additionally  be  recorded  on 
another  machine,  and  then  followed  by  a  series  of  messages  on  that 
other  machine  (recorded  as  the  activities  of  a  different  subject,  with 
the  same  identity),  but  there  is  always  an  easy  way  to  track  the  ori¬ 
gin  of  the  activity,  Therefore,  as  long  as  normal  administrative  pro¬ 
cedures  are  used  to  keep  the  clocks  in  different  machines  approxi¬ 
mately  synchronized,  the  time  stamps  in  audit  messages  will  be  in 
proper  sequence. 

Because  a  single  process  is  limited  in  the  number  of  files  it  can 
have  open  at  one  time,  the  merge  is  performed  in  multiple 
processes.  This  allows  audareduce  to  process  files  from  an  arbi¬ 
trarily  large  number4  of  machines.  Considerable  effort  has  been 
made  to  ensure  that  auditreduce  performs  efficiently  even  for  very 
large  configurations, 

Selecting  Audit  Messages 

The  other  half  of  auditreduce  is  message  selection:  choosing  which 
messages  will  be  passed  through  to  the  display  or  analysis  pro¬ 
grams.  Selection  options  are  provided  to  select  on  any  criterion 
which  can  be  assessed  from  a  single  message:  time,  type  of  mes¬ 
sage.  selection  class,  originating  user,  security  label,  etc.  The 
selections  are  all  performed  at  the  earliest  possible  point  in  the 
merge,  in  die  subprocesses.  This  reduces  the  amount  of  data  which 
travels  among  the  family  of  processes  creates  by  an  auditreduce 
invocation.  Selection  by  time  is  the  most  important  heavily  optim¬ 
ized  criterion:  as  described  above,  at  a  coarse  granularity,  messages 
can  be  selected  by  time  based  only  on  the  timestamps  in  filenames, 
and  without  opening  a  file  unless  it  is  known  to  contain  messages 
from  the  interval  of  interest. 

Audit  Migration  Facilities 

Some  miscellaneous  facilities  are  provided  by  auditreduce,  pri- 
marily  in  support  of  the  audit  file  migration  strategies  described 
above.  Messages  are  combined  from  multiple  files  into  one  using 
the  options  to  write  an  output  file,  delete  input  files,  and  read  all 
messages  from  any  input  flies  processed,  even  if  the  messages  are 
outside  the  specific  time  intervals  specified.  Input  files  can  be  in 
compressed  format,  and  output  files  may  be  requested  to  be  written 
in  compressed  format, 

Compression  is  performed  using  the  standard  SunOS  compress  pro¬ 
gram,  which  uses  adaptive  Lempel-Ziv  coding.  On  English  text, 


‘  Limited  only  by  configurable  table  tin  limits  in  ih*  turns!,  Ths  tmplomonuiian 
hss  worked  well  with  ovor  1090  Ales.  Tbs  number  at  lUss  which  must  b*  open  tt  s 
Umo  Is  equal  to  lho  number  at  mechlnee  which  generated  them:  exactly  one  Ale  si  e 
ilme  from  eech  mechlne  is  needed  beaus*  the  Ales,  ss  will  u  the  messt|se  in  them, 
ire  kept  In  strict  time  sequence. 


the  typical  compression  ratio  is  only  SO  to  60%,  but  on 
SunOS  MLS  audit  data,  it  generally  achieves  75%  to  90%  compres¬ 
sion.  These  ratios  can  be  achieved  with  audit  files  containing  1 
megabyte  of  data.  The  compression  is  most  efficient  when  large 
amounts  of  audit  data  are  being  collected,  since  when  a  single  pro¬ 
cess  generates  many  messages  in  rapid  succession,  the  messages 
will  usually  have  significant  redundant  content  which  can  then  be 
removed  by  compress. 


AUDIT  MESSAGE  FORMAT 

The  final  important  aspect  of  auditing  in  SunOS  MLS  is  the  format 
for  audit  messages.  Because  this  format  offers  significant  benefits 
for  third-party  software  developers,  it  is  being  proposed  as  an 
extension  to  the  IEEE  POSIX*  standard,  and  is  being  considered  by 
both  the  IEEE  P1003.6  committee  and  the  X/Open6  security  sub¬ 
committee. 

Goals 

The  basic  problem  which  makes  audit  messages  difficult  to  inter¬ 
pret  and  analyze  is  that  they  come  from  a  wide  variety  of  sources 
and  contain  many  different  types  of  information.  For  example, 
SunOS  MLS  can  generate  approximately  300  distinct  audit  mes¬ 
sages.  Despite  all  this  variety,  however,  the  messages  contain  only 
a  relatively  few  distinct  types  of  data  which  are  interesting  for 
analysis:  times,  labels,  file  pathnames,  subject  (process)  identities, 
etc.  The  multiplicity  of  formats  is  caused  by  the  need  to  report  dif¬ 
ferent  sets  of  these  datatypes  fot  different  operations. 

The  goals  of  the  audit  message  format  are  fourfold: 

1)  Easy  selection  of  audit  messages  on  a  variety  of  criteria; 

2)  Easy  addition  of  new  audit  messages  as  functions  are  added  to 
the  system  (without  changes  to  audit  analysis  tools); 

3)  Allowing  third-party  software  developers  to  create  additional 
audit  analysis  tools  which  arc  independent  of  a  particular  ver¬ 
sion  of  SunOS  MLS;  and 

4)  Allowing  third-party  software  to  generate  its  own  audit  mes¬ 
sages  which  can  be  meaningfully  analyzed  with  existing 
analysis  tools. 

The  initial  implementation  of  auditing  in  SunOS  MLS  did  not  met. 
these  goals.  It  used  an  inflexible,  fixed-format  message,  in  which 
additional  data  was  simply  tacked  on  following  the  header  in  a 
message-dependent  way.  As  a  consequence,  both  auditreduce  (for 
message  selection)  and  praudit  had  to  understand  the  format  of 
every  single  audit  message.  Whenever  a  new  type  of  audit  message 
was  added  to  the  system,  praudit  always  (and  auditreduce  often) 


*  POS1X  is  lb*  IHEE't  Potubl*  Operating  System  Interface  tpecif.cilion,  which  is 
bss*d  on  common  UNIX  system  tnlsrfecas.  Ths  PI  003.5  committee  ij  developing 
security  extensions  for  ths  beeic  PCS  EX  functions  suitsbls  for  ust  it  sla  TCSEC  levels, 

1  XXDpett  ii  tn  inumstlixul  orginixsllon  of  UNIX  system  vendors  which 
dev  dope  portability  etenderdt  beeed  on  lie  mambere'  eyslame.  The  locurity 
eubcommiuee  it  developing  eecurity  extensions  intended  primsrily  for  oommercisl 
ipplicslions  and  the  C2  TCSEC  level. 
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had  to  be  modified  to  understand  the  specific  message  format  asso¬ 
ciated  with  the  new  message  type.  This  was  clearly  undesirable 
even  within  the  scope  of  SunOS  MLS  development,  to  say  nothing 
of  its  consequences  for  third-party  developers.  As  a  message  for¬ 
mat,  it  satisfied  none  of  die  above  goals. 

The  remainder  of  this  section  discusses  how  dtese  goals  arc  met  by 
the  current  design. 

Audit  File  Format 


In  the  scheme  described  here,  an  audit  file  is  treated  as  a  sequen¬ 
tially  accessed  stream  of  bytes.  The  stream  is  broken  into 
variable-length  records.  Each  audit  file  contains  an  identifying 
header,  followed  by  an  arbitrary  number  of  records,  as  shown 
below: 


Header 


Message  #1 


Message  #2 


0  256 


327 


361 


NOTE:  The  numbers  along  the  bottom  of  all  die 
diagrams  indicate  byte  offsets  from  die  beginning.  In 
diis  diagram,  dicy  are  only  for  illustrative  purposes, 
and  do  not  represent  any  required  values. 

In  die  diagrams  showing  individual  tokens,  die 
number  at  dte  beginning  of  each  token  is  its  token 
type,  which  is  a  one-byte  value  appearing  at  die 
beginning  of  all  tokens  to  identify  their  contents, 


To  a  large  extent,  each  audit  message,  and  even  each  token  witltin 
the  message,  can  be  considered  independently  of  all  others,  which 
simplifies  interpretation  and  message  selection. 

There  are  three  classes  of  tokens:  Control,  Data,  and  Modifier 
(identified  as  C,  D,  and  M  in  the  table  below).  Each  of  dtese  classes 
contains  several  distinct  token  types,  idendfied  by  the  one-byte 
identifier  at  the  beginning  of  each  token.  There  are  currently  17 
defined  token  types. 

Control  tokens  are  essendally  part  of  the  audit  system’s  overhead: 
they  identify  the  beginning  (and  end)  of  messages.  Data  tokens 
provide  the  primary  idcndficadon  of  a  subject  or  object:  a  data 
token  should  provide  enough  information  to  know  what  the  mes¬ 
sage  is  referring.  A  data  token  may  be  followed  by  one  or  more 
modifier  tokens.  Modifier  tokens  provide  additional  information 
about  a  subject  or  object.  This  irtformadon  is  not  included  with  die 
data  tokens  for  two  reasons,  both  having  to  do  with  the  applicabil¬ 
ity  of  this  message  format  to  arbitrary  systems,  not  just 
SunOS  MLS,  First,  an  implementation  could  choose  to  save  space 
by  not  recording  information  that  its  customers  don't  care  about 
(for  example,  file  attributes  or  the  supplementary  group  list). 
Second,  an  implcmentadon  can  always  save  space  by  not  recording 
information  that  doesn't  make  sense  for  that  system  (such  as  labels 
in  a  C2  system).  These  variations  represent  an  implementation’s 
“auditing  style",  and  may  be  built  in  to  the  system  or  available  to 
an  administrator  as  configuration  options.  Because  the  individual 
audit  tokens  arc  largely  self-defining,  an  analysis  program  can  work 
regardless  of  the  auditing  style  of  the  system  generating  die  mes¬ 
sages. 
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AlUiough  the  size  is  arbitrary,  it  is  useful,  dtough  not  required,  to 
keep  dte  audit  files  to  a  manageable  size  by  periodically  instructing 
die  audit  daemon  to  switch  to  a  new  file. 

Although  diis  formal  allows  only  scquenual  access7,  and  does  not 
support  backward  reading  or  random  access,  its  simplicity  is  impor¬ 
tant.  because  it  allows  audit  data  to  be  passed  between  programs 
easily,  or  moved  between  systems  without  regard  to  internal  file 
formats. 

Flexible  Audit  Message  Format 

The  message  format  treats  each  audit  message  us  a  suing  of  “audit 
tokens".  Each  of  the  tokens  is  a  self-identifying  piece  of  duta, 
representing  a  file  padtnonc,  a  subject,  a  label,  etc.  The  token 
starts  with  an  identifying  byte,  which  is  followed  by  a  string  of 
bytes  representing  dte  rest  of  dte  data  in  a  token  type  dependent 
format.  A  message  looks  somudting  like  dtis: 
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Header 

u 

Subject 

Label 

13 

Puth 

Token 

Token 

Token 

Token 

0  1  13  14  24  25  56  57 


7  Thu  restriction  applies  only  to  the  simplest  implomcnutions.  The  TKAILKK 
lukui  type  allow*  hick  ward  folding  and  binary  Marching. 


The  average  size  of  SunOS  MLS  audit  messages  is  between  120 
and  180  bytes,  with  6  to  10  tokens  per  record.  The  compression 
typically  reduces  dte  message  size  U>  between  20  end  30  bytes  of 
compressed  data  per  message. 

Example  of  Audit  Message 

As  an  example,  the  audit  message  for  an  unlink 8  system  call  might 
contain  die  following  tokens,  laid  out  in  the  message  as  shown  in 
the  previous  diagr ->ms: 


Header  Token 
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1  The  operation  ujtlini  ( Path J  remove*  a  link  to  the  file  named  Path,  deleting  the 
file'*  content*  if  thet  war  the  last  link  to  the  file. 
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Label  Modifier  Token 


^  32-byte  binary  label 
|  (Sun  specific  format) 

0  1  22 


Pathname  Token 


1 

23 

Root 

Working 

Pathname 

Directory 

Directory 

Argument 

a 

1 

(variable) 

(variable) 

The  first  token,  present  in  all  audit  messages,  is  the  header,  which 
gives  the  type,  time,  class,  result,  and  length  of  the  entire  message. 
The  second  token,  present  in  most  messages,  identifies  the  subject 
performing  the  operation.  The  third  is  a  label,  the  label  of  the  sub¬ 
ject.  This  is  an  independent  (modifier)  token  to  allow  the  format  to 
be  used  on  systems  (such  as  class  C2)  which  do  not  implement 
labels  and  therefore  would  not  want  to  reserve  space  for  labels  in 
all  their  audit  messages.  The  fourth  token  is  the  file  pathname  for 
die  target  of  the  link. 

As  tills  is  an  example  only,  it  is  somewhat  simplified:  the  actual 
audit  message  for  unlink, )  also  includes  the  label  of  the  object 
being  unlinked  and  the  return  value  from  the  system  call  (to  indi¬ 
cate  success  or  failure). 

Audit  Token  Types 

The  message  header  token  is  present  in  all  audit  messages,  and  con¬ 
tains  three  pieces  of  information  in  a  fixed  formal:  the  message 
type,  the  time  the  message  was  generated,  and  die  total  length  of 
the  message.  The  total  length  of  the  message  is  used  to  allow 
sequential  processing  of  the  variable-length  messages.  The  mes¬ 
sage  type  is  used  to  identify  a  specific  operation,  such  as  a  system 
call  or  administrative  operation  (sec  Audit  Message  Pre-Selection, 
above). 

The  subject  token  identifies  a  subject  (process).  It  contains  the 
process’s  process  ID,  audit  user  ID,  real  user  ID,  and  effective  user 
ID.  For  a  system  widi  mandatory  access  control,  this  token  is 
always  followed  by  a  label  token  identifying  the  subject's  label. 
The  subject’s  audit  user  ID  is  an  identity  which  is  assigned  at  login 
time  and  cannot  be  changed  even  by  the  setuid  system  call  (unlike 
die  “real"  and  effective  user  IDs).  In  a  system  with  mandulory 
access  controls  (such  as  SunOS  M12>),  a  subject  token  is  always 
followed  by  a  label  modifier  token. 

The  file  path  token  type  contains  the  complete  pathname  needed  to 
identify  on  object,  including  the  process’s  current  root  directory 
and  working  directory,  os  well  as  die  name  which  was  supplied  for 
the  object  itself.  All  three  are  always  included,  even  diough  the 
patimamc  supplied  as  the  argument  to  a  system  call  might  be  an 
absolute  pathname,  making  the  working  directory  irrelevant,  Simi¬ 
larly  to  subject  tokens,  in  SunOS  MLS.  u  path  token  are  always  fol¬ 
lowed  by  a  label  modifier  token  unless  the  designated  object  does 
not  exist. 


In  addition  to  these  token  types,  there  are  odters  which  identify 
Two  additional  token  types  allow  the  inclusion  of  arbitrary  text  of 
binary  data  in  a  message.  These  are  used  when  die  data  does  not 
correspond  to  any  of  the  defined  token  types,  and  where  additional 
data  about  an  operation  is  required.  Text  and  data  tokens  are  dis¬ 
tinct  types  to  allow  the  analysis  tools  to  select  on  die  contents  of 
text.  An  opaque  data  token  is  generally  intended  for  interpretation 
by  a  special-purpose  analysis  tool,  whereas  the  text  token  and 
misccllaneous/arbitrary  data  tokens  are  intended  for  reading  by  a 
human  auditor. 


The  table  below  lists  all  the  defined  token  types,  dteir  class  (C  for 
control  tokens,  D  for  data  tokens,  M  for  modifier  tokens),  and  a 
brief  description. 


Name 

Class 

Description 

HEADER 

C 

Beginning  of  a  message  (length,  type,  time) 

TRAILER 

c 

End  of  a  message;  contains  die  length  for 
backward  reading 

SUBJECT 

D 

Subject  attempting  the  audited  operation 

SERVER 

D 

Identity  of  server  process  acting  for  subject 

DATA 

D 

Miscellaneous  binary  data;  includes  informa¬ 
tion  about  datatype  (character,  integer,  etc.) 
and  instructions  for  printing  (decimal,  hexa¬ 
decimal,  string,  etc.) 

PATH 

D 

Complete  pathnamc(s)  identifying  a  file  sys¬ 
tem  object  (root  directory,  current  directory, 
and  supplied  name) 

iih: 

D 

System  V  1PC  object  (Shared  Memory, 
Semaphore  Set,  Message  Queue) 

PROCESS 

D 

Process  that  is  target  of  operation 

TEXT 

D 

Text  message;  distinct  from  data  in  dial 
length  is  implicit,  reducing  the  token's  size 

RETURN 

D 

Return  value  and- error  code  from  system  call 

OPAQUE 

D 

Application-specific  structured  binary  data; 
generated  only  by  non-TCB  programs 

PACKET 

D 

Header  and  identifying  information  from  an 

IP  packet 

ATTR 

M 

Attributes  (type,  owner,  pennissions,  etc.)  of 
file  system  object 

IPC_ATTR 

M 

Attributes  of  System  V  1PC  object 

LABEL 

M 

Label  for  subjects  and  objects 

GROUPS 

M 

Group  list  (supplementary  group  IDs)  for  a 
subject 

NET.ADDK 

M 

Address  (4-byte  IP  format)  identifying  loca¬ 
tion  of  a  subject  or  object 

Writing  Audit  Messages 

To  furdier  ms-iau  ,.iograms  generating  audit  messages  from  dteir 
format  in  storage,  a  function  is  provided  which  ucccpts  as  argu¬ 
ments  die  message  type,  "i;'ss,  and  pointers  to  data  to  ire  inserted  us 
additional  tokens  in  the  me, sage.  F  -cause  a  file  token  is  generated 
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from  a  name  and  inode  pointer  (or  perhaps  just  a  name),  this  allows 
a  generating  program  to  supply  these  pointers  without  worrying 
about  whether  the  system  has  mandatory  access  control  so  that 
labels  have  to  be  included  in  the  audit  message. 

This  interface  is  available  both  within  the  kernel,  for  internal  use  by 
the  SunOS  MLS  TCB,  and  as  a  system  cali  for  use  by  the  trusted 
processes  in  the  SunOS  MLS  TCB  and  by  third-party  trusted 
software. 

Application-Generated  Audit  Messages 

The  system  allows  programs  oilier  than  die  supplied  TCB  software 
to  generate  audit  messages.  This  allows  an  installation  to  write 
programs  that  generate  audit  messages  describing  dieir  activities. 
Because  these  messages  use  die  some  token-based  format  as  TCB- 
gencraled  audit  messages,  diey  can  bo.  analyzed  widi  die  same 
tools. 

If  diese  messages  cuuld  mimic  die  messages  generated  by  TCB 
software,  or  in  some  way  overwhelm  die  audit  system's  capacity, 
die  integrity  of  die  audit  trail  would  be  lost.  The  system  protects 
against  this  in  two  ways.  First,  all  application- generated  messages 
are  identified  by  a  specific  message  type,  set  by  die  TCB  when  die 
message  is  written.  This  precludes  programs  from  imitating 
genuine  TCB  audit  messages  since  the  message  types  will  always 
differ.  Second,  application-generated  messages  belong  to  a  special 
class  of  audit  messages,  and  are  only  recorded  if  that  class  of  mes¬ 
sages  is  being  audited.  Thus,  the  system  administrator  can  control, 
oil  a  per-user  basis,  which  users  arc  permitted  to  generate  non-TCB 
audit  messages. 


IMPLEMENTATION  CHARACTERISTICS 

The  SunOS  MLS  audit  mechanism  is  quite  similar  to  odicr  UNIX- 
based  audit  implementations  (such  as  [GIigor86j  and  [Picciolo87|). 
The  principal  differences  arc  die  system- independent  nature  of 
message  and  file  formats  and  die  need  tor  a  "single-system  view" 
assembled  dynamically  (by  audilreduce)  from  a  potentially 
widely-distributed  collection  oT  audit  dala  files.  This  section 
explores  those  differences  and  summarizes  the  performance  charac¬ 
teristics  of  die  SunOS  MLS  implementation.  The  comparisons  arc 
not  made  widi  any  other  specific  systems,  but  rather  widi  general 
characteristics  dial  appear  in  many  systems. 

Comparison  With  Other  Implementations 

A  daemon  process  for  writing  audit  dala  was  chosen,  despite  the 
small  additional  overhead  it  entails,  to  de-couple  the  writing  of 
audit  data  from  its  generation  in  the  kernel.  This  simplifies  use  of 
die  audit  trail  by  non-kernel  software,  but  mostly  is  important 
because  it  allows  the  target  location  (file  or  otherwise)  of  audit 
messages  to  be  chosen  with  great  flexibility. 

The  additional  levels  of  buffering  bring  a  cost  in  reliability,  by 
increasing  the  amount  of  data  lost  in  the  event  of  failure,  but  this 
seems  more  than  compensated  fur  by  the  automatic  flic  switching 


capability  provided  by  the  daemon.  In  any  case,  the  maximum 
amount  of  data  loss  is  limited  and  predictable,  and  the  daemon 
structure  is  such  that  a  more  reliable  transport  mechanism  (or 
perhaps  one  using  non  erasable  optical  storage)  could  easily  be 
integrated,  whereas  such  a  change  might  be  very  difficult  in  a  sys¬ 
tem  where  the  kernel  do.s  all  message  processing  directly. 

Audit  messagi  ;  in  SunOS  MLS  arc  larger  than  in  many  odicr  sys¬ 
tems,  because  of  die  additional  information  they  include  for  identi¬ 
fying  objects,  This  resulted  from  a  tradeoff  between  simplicity  of 
analysis  tools  and  size  of  messages:  the  less  context  die  analysis 
tool  has  to  remember  (such  as  each  process’s  current  working 
directory),  die  easier  its  job  is.  In  practice,  diis  seems  hugely  com¬ 
pensated  for  by  the  degree  of  compression  provided  by  die 
compress  program.  When  the  audit  data  is  particularly  bulky  and 
contains  mostly  redundant  information,  compression  ratios  of 
nearly  8  to  1  are  possible.  Thus,  although  die  data  is  temporarily 
bulkier,  in  permanent  storage  (after  die  automatic  daily  consolida¬ 
tion),  die  bulk  is  comparable  to  odicr  implementations,  The  addi¬ 
tional  CPU  overhead  for  decompression  at  analysis  time  appears 
minimal. 

Similarly,  die  machine-independent  format  carries  a  significant 
space  penalty  relative  to  other  implementations,  and  again,  diis 
results  from  die  tradeoff  between  audit  trail  size  and  flexibility  of 
analysis  tools.  Tills  tradeoff,  too,  is  largely  masked  by  the 
efficiency  of  compression. 

Tite  audilreduce  program,  in  combination  widi  seif-identifying  data 
in  messages,  provides  essentially  all  die  types  of  selection  and 
analysis  that  can  be  provided  when  examining  messages  sequen¬ 
tially,  The  audit  class  mechanism  provides  some  capability  for 
pre-selection,  but  is  not  nearly  as  powerful  as  audilreduce. 

The  SunOS  MLS  audit  mechanism  is  intended  to  meet  or  exceed 
die  TCSEC  B1  requirements  specifying  which  events  are  to  be 
audited  and  what  forms  of  selective  auditing  may  be  performed. 
However,  it  is  also  intended  to  meet  practical  needs,  both  for 
human  auditors  and  automated  analysis  systems,  such  as  the  die 
Intrusion  Detection  Expert  System  (IDES)  (Lunt88|,  which 
analyzes  patterns  in  audit  data  to  detect  unauthorized  use  of  a  sys¬ 
tem.  The  capabilities  of  audilreduce  are  particularly  important  for 
manual  interpretation  of  audit  data. 

Performance  Characteristics 

As  SunOS  MLS  had  not  been  distributed  to  die  field  when  this 
paper  was  written,  these  numbers  are  necessarily  tentative.  How¬ 
ever,  they  indicate  that  die  size  of  data  collected  and  the  overhead 
for  collection  is  quite  comparable  to  that  for  odicr  systems.  Most 
of  the  numbers  below  describe  size  of  the  raw  binary  audit  data; 
compressed  data  is  treated  at  the  end. 

With  a  minimal  set  of  audit  classes  selected  (logins,  logouts,  and 
administrative  and  privileged  activity),  a  system  of  10  SunOS  MLS 
machines  (workstations  and  servers)  generates  about  100K.  bytes  of 
uncompressed  audit  data  per  day  for  the  entire  system.  If  auditing 
of  failed  operations  is  added,  this  increases  to  1-2  megabytes  per 
day.  If  auditing  of  all  event  classes  for  success  and  failure  is 
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enabled,  this  increases  to  10-30  megabytes  per  day  (again,  for  the 
whole  10-machine  sy;  tern).  It  must  be  emphasized  that  these 
numbers  are  generated  by  the  "normal”  activity  of  a  software 
development  group,  which  consists  primarily  of  text  editing  and 
compilation.  Any  heavy  file  system  activity  increases  the  bulk  con¬ 
siderably. 

The  maximum  capacity  of  the  audit  system  seems  to  be  about  20 
megabytes  of  raw  data  per  hour  on  a  typical  machine.  If  all  audit 
classes  are  turned  on,  and  the  machine  is  set  to  running  a  test  suite 
which  primarily  exercises  the  file  system,  it  can  generate  about  that 
much  data  in  an  hour.  The  machine  is  still  usable  in  this  state; 
although  performance  is  certainly  slowed,  normal  interactive  work 
can  still  take  place  in  much  the  same  way  as  on  a  slower  (previous 
generation)  machine. 

When  audit  data  is  compressed  (by  the  automatic  daily  consolida¬ 
tion),  typical  compression  ratios  range  from  3.5— to— 1  to  5-to-i. 
When  the  audit  data  is  heavily  redundant  (such  as  when  all  audit 
classes  are  selected),  the  compression  ratio  can  reach  8-to-l.  This 
reduces  a  daily  30  megabytes  to  7  or  8,  or  the  flat-out  20  megabytes 
per  hour  per  machine  to  a  more  manageable  2.5. 

Performance  of  any  audit  system  is  so  dependent  on  the  nature  of 
the  workload  as  to  essentially  defy  characterization.  With  the 
minimal  set  of  audit  classes  described  earlier,  the  performance 
impact  is  negligible.  Performance  impact  on  machines  used  as  file 
servers  is  also  essentially  negligible,  since  auditing  and  access  con¬ 
trol  is  performed  on  the  client  machines.  This  is  less  true  fot 
machines  used  as  servers  tor  file  systems  receiving  audit  data, 
although  even  there,  buffering  in  die  client  machines  reduces  the 
impact.  Since  a  SunOS  MLS  fiie  server  can  support  an  aggregate 
throughput  (for  all  its  clients)  exceed  200K  bytes  per  second,  even 
an  additional  20  megabytes  per  hour  represents  a  small  fraction  of 
that  capacity. 

Finally,  auditing  of  security-relevant  events  docs  not  affect  the  per¬ 
formance  of  CPU-bound  programs.  Because  a  SunOS  MLS  system 
is  typically  not  resource  limited  except  for  CPU-bound  jobs  or  rela¬ 
tively  brief  periods  of  heavy  I/O  activity,  the  most  important  meas¬ 
ure  of  auditing  performance  may  be  perceived  impact  on  response 
time,  which  is  minimal  because  of  die  high  performance  of  the 
individual  workstations. 


CONCLUSIONS 

Distributed  systems  pose  significant  difflculues  in  storing  audit 
messages.  Use  of  multiple  buffers  and  failure  recovery  algoridims 
makes  audiung  practical  and  efficient  in  a  distributed  system. 

The  auditreduce  tool  gives  the  administrator  of  a  distributed  system 
the  all-important  big  picture.  It  also  provides  the  management 
capabilities  for  maintaining  and  archiving  the  enormous  volumes  of 
audit  data  which  are  created  in  a  large  SunOS  MLS  configuration. 


work  is  planned  to  invesdgate  sclccuon  by  label,  by  object  identity, 
and  other  potentially  intcresdng  criteria.  Even  so,  the  current 
implcmentadon  allows  the  volume  of  audit  data  to  be  adjusted  over 
nearly  two  orders  of  magnitude. 

Because  of  die  general  message  format,  it  is  straightforward  to  use 
auditing  in  third-party  trusted  software,  and  to  create  third-party 
analysis  tools.  This  has  already  happened  within  Sun:  several  audit 
display  tools  have  been  created  outside  the  product  development 
effort,  and  it  is  hoped  'hat  similar  efforts  will  take  place  at  field 
sites  once  the  product  is  delivered. 

As  of  diis  writing,  there  is  too  little  experience  with  SunOS  MLS  to 
quandfy  die  performance  impact  of  audidng,  and  even  die  storage 
requirements  arc  not  entirely  clear. 
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Abstract 

Andrew  is  a  distributed  computing  environment  that  is  a  synthesis  of  the  personal  computing 
and  timesharing  paradigms.  When  mature,  it  is  expected  to  encompass  over  5000 
workstations  spanning  the  Carnegie  Mellon  University  campus.  This  paper  examines  the 
security  issues  that  arise  in  such  an  environment  and  describes  the  mechanisms  that  have 
been  developed  to  address  them.  These  mechanisms  include  the  logical  and  physical 
separation  of  servers  and  clients,  support  for  secure  communication  at  the  remote  procedure 
call  level,  a  distributed  authentication  service,  a  file-protection  scheme  that  combines  access 
lists  with  Unix  in  !e  bits,  and  the  use  of  encryption  as  a  basic  building  block,  The  paper 
also  discusses  the  assumptions  underlying  security  in  Andrew  and  analyses  Ihe  vulnerability 
of  the  system.  Usage  experience  reveals  that  resource  control,  particularly  of  workstation 
CPU  cycles,  is  more  important  than  originally  anticipated  and  that  the  mechanisms  available 
to  address  this  issue  arc  rudimentary. 


1.  Introduction 

Andrew  is  a  distributed  computing  environment  (hat  has  been  under 
development  at  Carnegie  Mellon  University  since  1983.  An  early 
paper  (181  describes  the  origin  of  the  system  and  presents  an  overview  of 
its  components.  Other  papers  [24.  10}  focus  on  the  distributed  file 
system  that  Is  the  information  sharing  mechanism  of  Andrew, 

The  characteristic  of  Andrew  that  has  influenced  almost  every  aspect  of 
its  design  is  its  scale.  The  belief  that  there  will  eventually  be  a 
workstation  for  each  person  at  CMU  suggests  that  Andrew  will  grow  into 
a  distributed  system  of  5000  to  10000  nodes  A  consequence  of  large 
scale  is  thut  the  laissez-faire  attitude  towards  security  typical  of  closely- 
knit  distributed  environments  is  no  longer  viable.  The  relative 
anonymity  of  users  in  a  large  system  requires  security  to  be  maintained 
by  enforcement  rather  than  by  the  goodwill  of  the  user  community. 

A  sizable  body  of  literature  exists  on  algorithms  for  security  In 
distributed  environments.  The  survey  by  Vnydock.  and  Kent  [28] 
describes  many  of  these  algorithms  and  discusses  the  basic  security 
problems  they  address.  In  contrast,  this  paper  focuses  on  the  design  and 
implementation  aspects  of  building  a  secure  distributed  environment.  It 
puts  forth  the  fundamental  assumptions  on  which  security  in  Andrew  is 
based,  examines  their  effect  on  system  structure,  describes  associated 
mechanisms,  and  reports  on  usage  experience. 


Andrew  is  a  joint  project  of  Carnegie  Mellon  University  and  the  IBM 
Corporation.  The  author  was  supported  in  the  writing  of  this  paper  by 
the  National  Science  Foundation  (Contract  No.  CCR-8657907).  The 
views  and  conclusions  in  this  document  are  those  of  the  author  and 
should  nol  be  interpreted  as  representing  ihe  official  policies  of  the 
Nalional  Science  Foundation,  the  IBM  Corporation  or  Carnegie  Mellon 
University. 


hough  Andrew  is  no  longer  an  experimental  system  it  is  far  enough 
turn  maturity  that  many  of  its  details  are  still  evolving.  Rallter  than 
trying  to  describe  a  moving  target,  this  paper  presents  a  snapshot  of 
Andrew  at  one  point  in  time.  The  point  of  reference  is  the  date  of  Ihe 
official  Inauguration  of  Andrew,  on  November  1 1  1986.  At  that  point  in 
time  there  were  over  400  Andrew  workstations  serving  ubout  1200  active 
users.  The  file  system  stored  15  gigabytes  of  data,  spread  over  15 
servers.  The  system  was  then  mature  and  robust  enough  to  be  in  regular 
use  in  undergraduate  courses  at  CMU  and  in  demonstrations  of  Andrew 
at  the  EDUCOM  conference  on  educational  computing.  In  the  rest  of 
(his  paper  the  present  tense  refers  to  the  slate  of  the  system  at  this 
reference  point.  Exceptions  to  this  are  explicitly  stated. 

The  paper  begins  with  an  overview  of  the  emiic  system  and  an 
identification  of  its  major  components.  Section  3  then  discusses  the 
underlying  assumptions  and  the  conditions  that  must  be  met  for  Andrew 
to  be  secure.  Sections  4  to  7  describe  the  protection  domain, 
authentication,  and  enforcement  of  protection  in  the  distributed  file 
system.  Section  8  discusses  the  problem  of  resource  control.  Section  9 
underlines  the  fundamental  role  of  encryption  and  ptoposes  that 
encryption  hardware  be  made  an  integral  part  of  all  workstations  in 
distributed  environments.  Section  10  deals  with  various  other  security 
concerns,  while  Section  1 1  examines  tire  ways  in  which  the  security  of 
Andrew  could  be  compromised  and  suggests  solutions  to  some  of  the 
possible  modes  of  attack,  Finally,  Section  12  ends  the  paper  with  an 
outline  of  changes  that  are  in  progress  or  have  occurred  since  the 
snapshot  presented  here. 

2.  System  Structure 

Andrew  combines  the  user  Interface  advantages  of  personal  computing 
with  the  data  sharing  simplicity  of  timesharing.  This  synthesis  is 
achieved  by  close  cooperation  between  two  kinds  of  components,  Vice 
and  Virtue,  Bhown  in  Figure  1.  A  Virtue  workstation  provides  the  power 
and  capability  of  a  dedicated  personal  computer,  while  Vice  provides 
support  for  the  limesharing  abstraction.  Although  Vice  is  shown  as  a 
single  logical  entity  in  Figure  1,  ii  is  actually  composed  of  a  collection  of 
servers  and  a  complex  local  area  network.  This  network  spans  (lie  entire 
CMU  campus  and  is  composed  of  Ethernet  and  IBM  Token  TUig 
segments  interconnected  by  optic  fibre  links  and  active  elements  called 
Routers.  Figure  2  shows  (he  details  of  this  network. 
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Endi  Viilue  workstation  inns  the  Unix  <1.2BSD  operating  system1  and  is 
thus  an  autonomous  timesharing  node.  Multiple  users  call  concurrently 
access  a  workslaiion  via  the  console  keyboard,  via  die  network  or  via 
lines  linn  arc  hardwired  to  the  workstation.  But  the  most  common  use  of 
a  workstation,  and  die  usage  mode  most  consistent  with  the  Andrew 
paradigm,  is  by  a  single  user  at  the  console. 

A  distributed  file  system  that  spans  all  workstations  is  the  primary  data- 
sluiriiij!  mechanism  in  Andrew.  In  Virtue,  this  file  syslcm  appears  as  a 
single  large  subtree  of  the  local  file  system.  Files  critical  to  the 
initialisation  of  Virtue  are  present  on  the  local  disk  of  the  workstation 
and  are  accessed  directly.  All  other  files  arc  in  the  shared  name  space 
and  are  accessed  through  an  intermediary  process  called  Venus  that  runs 
on  each  workstation.  Venus  finds  files  on  individual  servers  in  Vice, 
caches  (Item  locally  and  performs  emulation  of  Unix  file  system 
semunlics.  Both  Vice  and  Venus  arc  invisible  to  processes  in  Virtue.  All 
they  see  is  a  Unix  file  system,  one  subtree  of  which  happens  to  be 
identical  ott  all  workstations.  Processes  on  two  different  workstations 
can  read  and  write  files  in  this  subtree  just  as  if  drey  were  running  on  a 
single  timesharing  system. 

A  mainliiuiic  computer  that  rails  a  Venus  cun  also  share  Vice  files.  It  is 
more  likely  lo  have  multiple  concurrent  users  and  make  greater  use  of  ts 
local  file  syslcm  than  a  Virtue  workslaiion.  Il  will  probably  enforce  local 
resource  usage  controls  loo.  From  the  point  of  view  of  security  in 
Andrew,  however,  such  a  mainframe  is  no  differeni  from  a  Vntue 
woikstnlion. 

X  Assumptions 

Snlt/.cr  1 makes  an  itnpoi  Hint  distinction  between  a  scetoahle  syslcm 
and  specific  secure  instances  of  that  system.  Our  purpose  in  diis  section 
is  to  describe  die  level  of  security  offered  by  Andrew  mid  lo  stale  the 
assumptions  under  which  this  is  achieved.  The  degree  to  which  a 
specific  Andrew  site  is  secure  depends  critically  on  die  effort  taken  to 
meet  these  assumptions. 

II  is  easiest  lo  characterise  Andrew  using  the  taxonomy  introduced  by 
Voydock  and  Kent.  Their  survey  |28j  classifies  security  violations  into 
unauthorised  release  of  information,  modification  of  information,  and 
denial  of  resource  usage.  Hie  security  mechanisms  in  Andrew  primarily 
ensure  dial  information  is  released  ami  modified  only  in  authorised  ways. 
The  difficult  issue  of  resource  denial  is  not  fully  addressed.  The 
complexity  of  this  problem  is  apparent  if  one  considers  a  situation  where 
a  deleclive  piece  of  network  hardware  Hoods  die  network  with  packets. 
The  resulting  denial  of  network  bandwidth  lo  legitimate  users  is  clearly  a 
securily  violation  in  the  ■  riel  sense  of  die  term.  However,  il  is  nol  clear 
whin  Andrew  could  possibly  do  in  such  situations  except  lo  bring  (Ire 
problem  to  the  attention  of  system  administrators.  This  issue  of  resource 
control  is  discussed  at  length  in  Section  8. 

Alternative  taxonomies  of  security  also  exist.  Walt  [30|.  lor  instance, 
considers  the  security  of  the  Hytlta  operating  system  in  die  light  of  the 
problems  of  mutual  snspieitm,  modification .  ctinscrvation ,  confinement . 
and  initialization.  II  is  more  difficult  lo  characterise  Andrew  within  this 
framework.  Since  Vice  and  Viriue  do  nol  trust  each  oilier  until  a  user 
successfully  executes  the  nutherdication  procedure  described  in  Section 
5.  there  is  indeed  muluul  suspicion.  Bui  users  do  depend  on  Vice  lo 
provide  safe,  long-  term  siorage  of  tiled  files  and  to  enforce  their 
protection  policies.  Andrew  can  protect  against  modification  of  files  by 
oilier  users,  hul  there  is  no  safeguard  against  incorrect  modifications  by 
Vice  itself.  Since  Andrew  supports  revocation  it  does  address  the 
problem  of  conservation.  But  die  problem  of  confinement,  extensively 
discussed  by  I-ampson  [I5|.  is  one  that  Andrew  makes  no  attempt  lo 
solve.  Il  is  not  clear  how  the  initialization  problem  in  Wulfs  model 
applies  lo  Andrew. 


Tile  Department  of  Defense  taxonomy  of  computer  systems  described  h;. 
Schell  1261  classifies  computer  systems  into  four  major  categories  with 
numerous  subcalegorics.  Securily  ranges  in  strength  from  class  D 
[minimal  protection )  to  class  A2  {verified  implementation),  in  this 
classification  scheme.  Andrew  appears  to  111  best  into  class  C2 
{controlled  access)  or.  possibly,  B 1  ( labelled  security). 

For  simplicity,  we  shall  restrict  our  attention  in  the  rest  of  Ibis  paper  lo 
the  model  pul  forth  by  Voydock  and  Kent.  We  do  recognise,  however, 
that  a  complete  analysis  of  Andrew  security  in  terms  of  n  variety  of 
taxonomies  would  he  a  valuable  exercise  in  itself. 

A  fundamental  assumption  pertains  io  lire  question  of  who  enforces 
security  in  Andrew.  Rattier  than  trusting  thousands  of  workstations, 
security  in  Andrew  is  predicated  on  the  integrity  of  tile  much  smaller 
number  of  Vice  servers.  These  servers  are  located  in  physically  secure 
rooms,  are  accessible  only  to  trusted  operators,  and  run  software  that  is 
above  suspicion.  No  user  software  is  ever  run  on  servers.  For 
operational  reasons,  it  is  necessary  lo  provide  utilities  that  can  be  run  on 
servers  to  directly  manipulate  Andrew  file  system  data.  These  utilities 
can  be  ran  only  by  superusers  on  servers.2  Both  access  to  servers  and  the 
ability  to  become  superuser  on  them  must  be  closely  guarded  privileges. 

Workstations  may  be  owned  privately  or  located  in  public  areas,  We 
assume  that  owners  may  modify  both  the  hardware  and  software  on  their 
workstations  in  arbitrary  ways.  It  is  therefore  the  responsibility  of  the 
user  to  ensure  that  lie  is  nol  being  compromised  by  software  on  a  private 
workslaiion.  Such  a  piece  of  soflware,  referred  lo  as  a  Trojan  Iwrse  |9|. 
is  trivially  installed  by  a  superuser.  Consequently  the  user  lias  lo  trust 
every  individual  who  has  the  ability  lo  become  superuser  on  the 
workstation.  A  user  who  is  seriously  concerned  about  security  would 
ensure  the  physical  integrity  of  his  workslaiion  and  would  deny  all 
remote  access  to  il  via  the  network. 

In  the  case  of  a  public  workstation,  il  is  assumed  that  there  is  constant 
surveillance  by  administrative  personnel  lo  ensure  the  integrity  of 
hardware  and  software.  It  is  relatively  simple  to  visually  monitor  ami 
detect  hardware  tampering  in  a  public  area.  But  it  is  much  harder  to 
detect  a  miscreant  becoming  superuser  and  installing  a  Trojan  horse. 
Keeping  the  superuser  pussword  on  a  workstation  secret  Is  not  adequate 
because  workstations  can  be  easily  booled  up  standnlonc.  with  the  person 
at  the  console  acquiring  superuser  privileges.  An  organisation  that  is 
serious  aboul  securily  would  have  lo  physically  modify  workstalions  so 
that  only  authorized  personnel  can  bool  up  public  worksiaiions 
standalone.  Ai  the  prescnl  tune  public  workstations  at  CMU  do  not  have 
such  physical  safeguards. 

Il  is  common  for  a  pool  of  private  workstalions  to  be  used  by  a  small 
collection  or  users.  Workstations  located  in  shared  offices  or 
laboratories  arc  examples  of  such  situations.  From  the  point  of  view  of 
security,  such  workstations  are  effectively  co-owncd  by  all  users  who 
can  physically  access  them.  It  is  their  joint  responsibility  to  ensure  the 
integrity  ol  the  hardware  and  software  on  the  workstations. 

It  should  be  emphasised  dial  die  preceding  discussion  of  software 
integrity  on  workstations  pertains  lo  local  files.  There  are  usually  only  a 
few  such  files,  typically  system  piogrums  for  initialising  die  workstation 
and  for  audicnlicating  users  to  Vice.  All  other  user  files  are  stored  in 
Vice  anil  ire  subject  io  the  safeguards  discussed  in  Section  6. 

The  network  underlying  Andrew  has  segments  in  every  building  at 
CMU,  including  student  dormitories.  Il  is  impossible  to  guarantee  the 
physical  integrity  ul  this  network.  Il  can  be  tapped  at  any  point,  ami 
private  workstalions  with  modified  operating  systems  can  eavesdrop  on 
network  traffic.  A  consequence  of  these  observations  is  that  end-to-end 
mechanisms  based  on  encryption  arc  the  only  way  to  ensure  secure 
communication  between  Vice  and  Virtue.  These  mechanisms  are 
described  in  Set  don  5. 


'Unix  is  u  injilemurk  of  AT&T.  routers  shewn  lit  Figure  2  arc  dedicated  computers  that  run 

3Thc  server*  nlso  ron  Unix  4.2BSD.  A  "lupenisci "  is «  privileged  Unix  user  free  of  specialised  software.  Tile  integrity  of  these  routers  is  nol  critical  IO 
nomiul  ull-cnx  irKtriiuiiws-  Andrew  security.  Because  Andrew  uses  end-to-end  encryption,  a 

compromised  router  cannot  expose  or  modify  information  that  is 
transmitted  tlirough  il.  At  worst,  it  can  cause  packets  to  be  misrouted  or 
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modified  in  ways  that  cause  the  receiver  to  reject  them,  These  arc 
essentially  cases  of  resource  denial,  which  Andrew  docs  not  attempt  to 
address  completely.  Physical  damage  to  a  network  segment  has  similar 
consequences. 

Finally,  the  design  of  the  Andrew  file  system  postulates  the  use  of  an 
independent,  secure  communication  channel  connecting  all  the  Vice 
servers.  This  is  used  for  administrative  functions  such  as  tape  backups 
and  distribution  of  the  prolection  database  described  in  Section  4.  This 
sccuie  channel  has  to  be  realised  either  by  a  separate,  physically  secure 
network  or  by  the  use  of  end-to-end  encryption  as  in  the  case  of  Vice- 
Virtue  communication.  At  the  present  time,  neidter  of  these  of  measures 
is  used  at  CMU.  lire  secure  communication  channel  is  die  same  as  the 
public  network,  and  communication  on  it  is  unencrypted. 

4.  Tlu*  Protection  Domain 

Tlte  fundamental  protection  question  is  "Can  agent  X  perform  operation 
y  on  object  Z!"  We  refer  to  the  set  of  agents  about  whom  such  a 
question  can  Ik'  asked  as  the  Protection  Domain  |23|.  In  Andrew,  the 
protection  domain  is  composed  of  Users  and  Groups.  A  user  is  an  entity, 
usually  a  human,  that  can  authenticate  itself  to  Vice,  be  held  responsible 
for  its  actions,  and  be  charged  for  resource  consumption.  A  group  is  a 
sol  of  other  groups  and  users,  associated  with  a  user  called  its  Owner. 
The  name  of  the  owner  is  a  prefix  of  the  name  of  the  group,  it  is  possible 
to  impose  meaningful  stntciure  in  die  names  of  groups,  although  Andrew 
ignores  such  structure.  For  example,  "DoviktFricnds", 
"BoviktFriends.CaiLovcfs",  and  "Bovik:Fricttds.CalHaiers"  could 
mticmonically  indicate  the  purpose  of  three  groups  owned  by  user 
"Bovik". 

Vice  internally  identifies  users  and  groups  by  unique  32-bit  integer 
identifiers.  An  id  cannot  be  reassigned  alter  creation.  Such 
reassignment  would  require  elimination  of  all  existing  instances  of  the  id 
from  long-term  Vice  data  structures,  an  operational  nightmare  in  a  large 
distributed  system.  User  and  group  names,  on  die  oilier  hand  can  easily 
be  changed. 

A  distinguished  user  named  “.System"  is  omnipotent;  Vice  applies  no 
protection  checks  to  it.  Our  original  intent  was  that  "System"  would 
play  the  same  role  that  a  superuser  plays  in  Unix  systems,  in  practice  we 
have  found  it  more  convenient  to  define  a  special  group  named 
‘ System: Administrators. ’  ’  It  is  membership  in  this  group  rather  than 
authentication  as  "System"  that  now  endows  special  privileges.  An 
advantage  of  litis  approach  is  tltal  the  actual  identity  of  the  user 
exercising  the  privileges  is  available  for  use  in  audit  trails.  Wc  consider 
this  particularly  iniporlani  in  view  of  the  scale  of  Andrew.  Another 
advantage  is  that  revocation  of  special  privileges  can  be  done  by 
modifying  group  membership  rattier  titan  by  changing  a  password  and 
communicating  it  securely  to  the  users  who  arc  administrators. 

The  protection  domain  includes  two  other  special  entities:  the  group 
"SystenuAnyUscr".  which  has  all  authenticated  users  of  Vice  as  its 
implicit  members,  and  tile  user  "Anonymous”  corresponding  to  an 
unaiillieiiticalcd  Vice  user.  Neither  of  these  special  entities  can  be  made 
a  member  of  any  group.  Although  the  current  implementation  blurs  the 
distinction  between  these  two  entities-*,  we  forsec  situations  where  the 
distinction  would  be  valuable.  For  cxa-tiplc.  when  the  support  for 
independent  administrative  domains  discussed  in  Section  10.3  is 
operational  il  would  be  convenient  to  be  able  to  recognize  and  grant 
specific  privileges  to  all  authenticated  members  of  a  particular 
administrative  domain. 


Files  uloietl  in  Vice  by  ;ui  uiiuuthcnticnted  user  appear  as  if  they  were  stoicrl  by 
' Syrlcm: Any! l-tr"  rattier  tliuri  by  " Anonymous,'1 

JOm  rue  of  [he  group  ‘ ‘System: Adm ini r Inn ors"  rather  tliuri  Ihe  pseudo-uscr 
"System"  iv  motivuled  in  piul  by  this  concent. 


Membership  in  a  group  can  be  inherited.  The  IsAMemberOj  relation 
holds  between  a  user  or  group  X  and  a  group  O',  if  ami  only  if  X  is  a 
member  of  G.  The  reflexive,  transitive  closure  of  this  relation  for  X 
defines  a  subset  of  the  protection  domain  called  its  Current  Protection 
Subdomain  (CPS).  Informally,  die  CPS  is  the  set  of  till  groups  dial  X  is  a 
member  of.  either  directly  or  indireclly,  including  X  itself.  This 
hierarchical  structuring  of  the  protection  domain  is  similar  to  tlte 
schemes  hi  the  CMU-CFS  file  system  [  I  ]  and  Grapevine  [3). 

Tite  CPS  is  important  because  the  privileges  lltal  a  user  lias  at  any  time 
arc  the  cumulative  privileges  of  all  the  elements  of  his  CPS.  For 
example,  suppose  "SystenuCMU",  "  SystenuCMU. Faculty ' '  and 
“Systcm:CMU.Studcnts"  are  three  groups  with  tire  obvious 
interpretations.  If  ihe  second  and  third  groups  are  members  of  die  first, 
new  additions  to  those  groups  will  automatically  acquire  privileges 
granted  to  "SystcmiCMU."  Conversely,  when  a  student  or  faculty 
member  leaves,  il  is  only  nccessaiy  to  remove  hint  from  those  groups  in 
which  lie  is  explicitly  named  as  a  member.  Inheritance  of  membership 
thus  conceptually  simplifies  Ihe  maintenance  anil  administration  of  the 
protection  domain.  Tlte  scale  of  Andrew  makes  tilts  an  iniporlani 
advantage. 

A  common  practice  in  timesharing  systems  is  to  create  a  single  entry  in 
the  protection  domain  to  stand  for  a  collection  of  users.  Such  a  collective 
entry,  often  referred  to  as  a  "group  account"  or  a  "project  account." 
may  be  used  for  a  number  of  reasons.  First,  obtaining  an  individual  entry 
for  each  human  user  may  involve  excessive  adntinislrulivc  overheads. 
Second.  Ihe  identities  ol  all  collaborating  users  may  not  he  known  a 
prioti.  Third,  the  protection  mechanisms  of  (lie  system  may  make  it 
simpler  to  specify  protection  policies  in  terms  of  a  single  pseudo-user 
than  for  a  number  of  users. 

We  believe  dial  litis  practice  should  be  strongly  discouraged  in  an 
environment  like  Andrew,  Collective  entries  will  exaeeibate  tlte  alreatly- 
diffieull  problem  of  accountability  in  a  large  distributed  system.4  The 
hierarchical  organisation  of  lltc  protection  domain,  in  conjunction  with 
tlte  access  list  mechanism  described  in  Section  b.  make  the  specification 
ol  protection  policies  simple  in  Andrew.  In  spile  of  this  we  arc 
disappointed  to  observe  (hat  there  are  some  collec  tive  entries  a'  CMU. 
We  conjecture  that  this  is  primarily  because  tin:  addition  of  n  new  user  is 
cumbersome  at  present.  In  addition,  groups  can  only  be  created  and 
modified  by  system  administrators.  As  discussed  in  Section  12,  these 
problems  are  being  addressed  and  we  hope  lltal  collective  entries  will 
soon  become  unnecessary. 

5.  Aiilhcniiutlion  and  Secure  Catiiiniinicatioii 
Authentication  is  the  indisputable  establishment  of  identities  between 
two  mutually  suspicious  parlies  in  the  face  of  adversaries  witli  malicious 
intent.  In  Andrew,  the  two  parties  ate  a  user  at  a  Virtue  workstation  tutd 
a  Vice  server,  wltile  the  adversaries  are  eavesdroppers  on  lltc  network  or 
modified  network  hardware  that  alters  die  data  being  transmitted. 

From  a  user's  point  of  view,  using  Viituc  seems  no  different  from  using 
a  standalone  workstation.  In  response  to  a  standard  Unix  login  prompt, 
(lie  user  provides  his  name  and  password.  While  logged  in.  lie  may 
access  local  files  as  well  as  Vice  files  located  on  many  servers.  Venus 
establishes  secure,  attthenlicnied  eonneclions  lo  litesc  servers  as  they  are 
needed.  The  cslablislimcnt  of  a  connection  is  completely  transparent  lo 
the  user,  in  parlicular,  he  does  not  have  to  supply  his  password  caclt 
lime  a  new  connection  is  made. 

lire  authentication  mechanism  we  use  is  a  derivative  of  Needham  and 
Schroedcr's  original  scheme  [19]  using  private  encryption  keys.  The 
overall  function  is  decomposed  into  three  inDor  components: 

•  a  Remote  Pnnedure  Cal!  mechanism  dim  i»ovides  support 
for  security. 

•  a  scheme  for  obtaining  and  using  Authentication  Tokens. 

•  an  Authentication  Server  that  is  a  repository  of  password 
information. 
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5.1.  Secure  RPC 

Early  in  our  implementation,  it  became  dear  that  the  remote  procedure 
call  package  used  between  Vice  and  Virtue  was  u  natural  le -cl  of 
abstraction  at  which  to  provide  support  for  secu.c  communication. 
Birrcll's  report  on  security  in  the  Cedar  RPC  package  [4]  independently 
confirmed  the  validity  of  our  decision. 

The  imerface  of  the  RPC  package  is  described  in  detail  in  the  user 
manual  (25|.  '.Vhcn  a  clicnl  wishes  to  communicate  with  a  server,  it 
executes  a  BIND  operation  that  sets  up  a  logical  Connection.  Connections 
are  relatively  cheap  to  establish  and  require  only  about  a  hundred  bytes 
of  storage  overhead  at  each  end.  A  connection  —  set  up  to  be  at  one 
of  four  levels  of  security: 

OpcnKinwno  neither  authenticated  nor  encrypted. 

AuthOnh  authenticated,  but  RPC  packets  not  encrypted. 

HcadersOnly  authenticated  and  RPC  packet  headers,  but  not 
bodies,  encrypted. 

Sttiin’  authenticated,  and  RPC  packets  fully  encrypted, 

Only  the  last  of  these  four  levels  provides  true  end-to-end  security;  the 
second  and  third  levels  are  provided  as  a  compromise  between  security 
and  efficiency,  and  the  first  can  be  used  when  secure  communication  is 
im  required. 

A  client  etui  specify  the  kind  of  encryption  to  be  used  when  establishing 
a  connection.  The  server  provides  a  bit  mask  indicating  lire  kinds  of 
encryption  it  can  handle,  and  will  reject  attempts  by  a  client  to  use  any 
other  kind.  Tills  flexibililty  makes  it  feasible  to  equip  servers  with 
encryption  hardware  us  well  as  a  suite  of  softwure  encryption  algorithms 
of  differing  strength  and  cost.  A  workstation  owner  can  make  a  tradeoff 
between  economy,  performance  and  degree  of  security  in  determining 
the  kind  of  encryption  to  use.  The  preferred  approach  is,  of  course,  io 
equip  all  workstations  with  encryplion  hatdware.  Seclion  9  discusses 
encryption  in  greater  detail. 

For  all  tile  authenticated  security  levels,  tile  BIND  operatiott  involves  a 
3-phase  handshake  between  client  and  server.  The  client  side  of  the 
application  provides  u  variable-length  byte  sequence  called  Clientldent. 
tuid  an  8-byte  encryption  key  for  the  handshake.  The  server  side  of  the 
application  supplies  a  procedure.  GetKeys.  to  perform  key  lookup  and  a 
ptoccdttrc.  AuthFail,  to  be  invoked  on  authentication  failure.  The  latter 
allows  the  server  to  record  and  possibly  notify  an  administrator  of 
suspicious  authentication  failures. 

At  die  cud  of  a  successful  ItrND.  the  server  is  assured  that  the  client 
possesses  the  correct  handshake  key  for  Cliemldein.  The  client,  in  turn, 
is  assureil  that  tiic  server  is  capable  of  deducing  the  handshake  key  from 
Client  Idem.  The  possesion  of  (he  handshake  key  is  assumed  lo  be  prima 
facie  evidence  of  authenticity. 

The  steps  performed  by  (lie  RPC  package  during  BIND  are  as  follows: 

1 .  The  client  chooses  a  random  number,  Xr  and  encrypts  it 
with  its  handshake  key.  HKC.  it  sends  the  result.  (X,)™' . 
and  Clientldent  (in  the  clear)  lo  the  server. 

2.  When  the  BIND  request  arrives  at  the  server,  (lie  RPC 
package  invokes  GetKeys  with  Clientldent  as  a  parameter. 

3.  GetKeys  does  a  key  lookup  and  returns  two  keys.  One  of 
these  keys  is  a  handshake  key,  HKS.  and  the  other  is  a 
session  key,  SK,  to  be  used  after  the  connection  is 
established.  If  the  return  code  from  GetKeys  indicates  that 
tile  key  lookup  was  unsuccessful,  (he  BIND  request  is 
rejected  immediately  and  AuthFail  is  invoked  with 
Clientldent  and  the  network  address  of  die  client  as 
parameters. 

4.  Otherwise  the  server  decrypts  lXr)mc  with  its  handshake 
key,  yielding  ((Xr)"*c)"*J. 

3.  The  server  adds  one  to  the  result  of  its  decryption,  then 
encrypts  this  anti  a  new  random  number,  Yr,  with  its 
handshake  key.  It  sends  the  result,  U((Xry"t!Yu:i+l), 
Yr)hX\  to  the  client. 


6.  The  client  uses  its  handshake  key  to  decrypt  this  message. 

If  HKC  and  HKS  match,  the  first  number  of  the  decrypted 
pair  will  be  (Xr+1).  If  this  is  the  case,  the  client  concludes 
that  the  server  is  genuine.  Otherwise  the  server  is  a  fake 
and  BIND  terminates. 

7.  The  client  adds  one  to  the  second  number  of  the  decrypted 
pair  and  encrypts  it  with  its  handshake  key.  It  sends  the 
result.  (((Y ryi!yiKc  +  j  y«rc  t0  ,hc  servcri 

8.  The  server  deer,  pts  this  message  with  its  handshake  key. 

If  HKC  and  HKS  match,  the  decrypted  number  will  be 
(Yr+U.  In  that  case  the  server  concludes  that  the  client  is 
genuine.  Otherwise  the  client  is  a  fake  and  the  BIND 
terminates  aftei  AuthFail  is  invoked. 

9.  The  server  then  encrypts  the  session  key.  SK,  and  a 
randomly  chosen  initial  RPC  sequence  number,  rO.  with  it: 
handshake  key.  it  completes  BIND  by  sending  the  result, 

(Sk.  xO)"KS,  to  the  client.  All  future  encryption  on  this 
connection  uses  SK.  The  sequence  numbers  of  RPC 
requests  and  replies  will  increase  monotonically  from  xO. 

■file  correctness  of  this  authentication  procedure  hinges  on  the  fact  that 
possession  of  the  handshake  key  by  both  parlies  is  essential  for  all  steps 
of  the  handshake  to  succeed.  Without  the  correct  key,  it  is  extremely 
unlikely  lhal  an  adversary  will  be  able  lo  generate  outgoing  messages 
thai  correspond  lo  appropriate  transformations  of  the  incoming  messages. 
Mutual  authentication  is  achieved  because  both  tiie  client  and  the  server 
are  required  lo  demonstrate  that  they  possess  tile  handshake  key.  The 
use  of  new  random  numbers  for  each  BIND  prevents  an  adversary  from 
eavesdropping  on  a  successful  BIND  and  replaying  packets  from  that 
sequence. 

Figure  3  summarises  the  steps  involved  in  the  BIND  authentication 
procedure.  It  is  imporlant  to  note  that  the  RPC  package  makes  no 
assumptions  about  the  format  of  Clientldent  or  the  manner  in  which 
GetKeys  derives  the  handshake  key  from  Clientldent.  The  next  section 
describes  how  this  generality  is  used  in  Andrew  in  two  different  ways:  at 
login,  to  communicate  with  an  authentication  server,  and  each  time 
Venus  contacts  a  file  server.  A  connection  is  terminated  by  an  UNBIND 
call  which  deslroys  all  stale  associated  with  that  connection. 

Security  in  Andrew  is  not  critically  dependent  on  the  details  of  the 
authentication  handshake.  The  code  pertaining  to  il  is  small  and  self- 
contained.  Tliu  handshake  am  therefore  be  treated  as  a  black  box  and  an 
alternative  mulual  authentication  technique  subsliluted  with  relative  case. 

5.2,  Authentication  Tokens 

Andrew  uses  a  two-step  authentication  scheme  based  on  Tokens  for 
reasons  of  transparency  us  well  as  robustness.  This  approach  provides  a 
number  of  advantages  over  a  single-step  authentication  scheme: 

1 .  It  allows  Venus  to  cslablish  secure  connections  as  il  needs 
them,  without  users  having  to  supply  their  password  each 
time. 

2.  Il  avoids  having  to  store  passwords  in  the  cleat  on 
workstations. 

3.  It  limits  the  time  duration  during  which  lost  tokens  can 
cause  damage, 

4.  It  allows  system  programs  other  than  Venus  to  perform 
Vice  authentication  without  user  intervention. 

Authentication  tokens  arc  pairs  of  objects  whose  possession  is  indirect 
proof  of  authenticity.  Such  a  pair  is  like  a  Capability  [14]  in  that  no 
consultation  with  an  external  agency  is  required  when  using  them,  but  is 
different  from  a  capability  in  that  it  establishes  identity  rather  than 
granting  rights.  Tokens  are  conceptually  similar  to  Authenticators 
described  by  Birrell  [4], 

One  of  the  components  of  the  pair,  the  Secret  Token,  is  encrypted  at 
creation  and  can  be  sent  in  the  dear.  The  other  component,  the  Clear 
Token ,  has  fields  that  are  sensitive  and  should  be  sent  only  on  secure 
connections.  Both  tokens  contain  essentially  the  same  information:  the 
Vice  id  of  the  user,  a  handshake  key,  a  unique  handle  for  identifying  the 
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token,  u  timestamp  that  indicates  when  the  token  becomes  valid,  and 
another  timestamp  that  indicates  when  it  expires.  The  secret  token 
contains,  in  addition,  a  fixed  string  nr  self-identification.  The 
appearance  of  this  string  when  decrypting  secrcl  token  confirms  that 
the  right  key  has  been  used.  The  secret  token  also  contains  noise  fields 
that  are  filled  with  new  random  values  each  tine  a  token  is  created.  This 
is  done  to  thwart  attempts  to  break  the  key  used  for  encrypting  tokens. 

The  Unix  program  tor  logging  in  on  worksiat  oils  has  been  extensively 
modified,  although  its  user  interface  is  unaltered.  LOGIN  now  contacts  an 
authentication  server  using  the  RPC  mechanism  described  in  Section  5.1. 
The  name  and  password  typed  in  by  the  user  ate  used  as  die  ClictUideni 
and  handshake  key  respectively.  The  C  el  Keys  roulin  in  the 
authentication  server  obtains  this  password  from  an  internal  table.  When 
the  RPC  handshake  completes,  a  secure,  authenticated  connection  has 
been  established  between  LOGIN  anil  the  authentication  server.  login 
uses  this  connection  to  obtain  a  pair  of  tokens  for  ih„  user.  The 
authentication  server  gene -ales  a  new  handshake  key  tor  each  pair  of 
tokens  it  creates.  It  encrypts  the  secret  token  with  a  key  known  only  to 
itself  and  (he  Vice  file  servers,  login  now  passes  the  clear  ami  secret 
tokens  to  Venus,  which  retains  them  in  an  internal  data  structure.  At  this 
point  Login  terminates,  and  the  user  can  use  the  workstation. 

Whenever  Venus  needs  to  establish  an  RPC  connection  to  a  Vice  file 
server  on  behalf  of  a  user,  it  invokes  HIND  using  ihe  secret  token  for  that 
iser  as  Cliemldenl  and  ihe  key  in  (lie  clear  token  as  Ihe  handshake  key. 
In  the  first  phase  of  the  BIND,  die  GctKeys  routine  on  the  serve  is 
Invoked  with  Clietuldem  as  the  input  parameter.  The  server  obtains  the 
handshake  key  from  the  scero:  token  after  decrypting  it.  The 
aulhenlicntion  procedure  is  critically  dependent  on  the  assumption  that 
only  legitimate  servers  possess  the  key  to  decrypt  secret  tokens.  At  this 
point  Venus  am!  the  server  each  have  a  key  that  they  believe  lo  be  the 
coned  handshake  key.  The  remaining  steps  of  the  HIND  proceed  as 
described  in  Section  5.1 ,  leading  lo  mutual  authentication.  If  (lie  HIND  is 
successful,  llte  server  uses  Ihe  id  in  (he  secret  token  as  the  identity  ol  the 
client  on  litis  RPC  connection  and  sels  up  apptopriatc  internal  stale. 

Since  tokens  have  a  finite  lifetime,  a  user  will  need  lo  periodically 
reuuihemiciiie  himself.  Al  present,  tokens  are  valid  for  24  hours  at 
CMU.  The  program  LOG,  which  is  functionally  idenlical  to  LOGIN,  can 
I  '  used  lor  rcniilhcnlicution  without  explicitly  logging  out.  This  allows 
'  retain  logged-in  context. 

\\  multiple  users  are  logged  into  a  worksuuion.  Venus  maintains  a 
sc  .rale  , secure  RPC  connection  for  cad-  'f  them  for  each  of  tire  Vice 
file  servers  they  have  accessed.  When  a  user  logs  out  of  n  workstation. 
Venus  deletes  his  lokens.  In  die  future  Vice  may  support  oilier  services 
besides  a  dis'ributctl  file  system,  llte  components  of  such  services 
which  execute  in  Virtue  will  lie  able  lo  use  tokens  for  authentication,  just 
as  Venus  does  at  present. 

5.5.  Authentication  Server 

The  authentication  server,  which  runs  on  a  trusted  Vice  machine,  is 
responsible  for  restricting  Vice  access  and  for  determining  whether  an 
aiilheillicaliim  attempt  by  a  user  is  valid.  To  perlorill  these  functions  it 
maintains  a  database  of  password  information  about  users.  An  excerpt  of 
tins  database  is  shown  in  Figure  4.  The  passwords  stored  in  the  database 
are  effectively  ill  die  clear,  but  are  encrypted  with  a  key  known  to  the 
server  so  that  lion-malicious  system  personnel  are  prevented  from 
accidentally  reading  the  passwords.  This  database  is  used  for  password 
lookup  whcni'vci  a  user  logs  in  to  a  Virtue  workstation,  it  is  updated 
whenever  a  user  is  created,  deleted  or  has  his  name  or  password  changed. 
Users  can  change  their  own  password;  oilier  operations  tan  only  be 
performed  by  system  administrators. 

Server  performance  is  considerably  improved  by  exploiting  the  fact  that 
quei  ies  are  Tar  more  frequent  titan  updates.  This  makes  it  appropriate  for 
the  server  to  maintain  a  write-through  cache  copy  of  the  entire  database 
in  its  virtual  memory.  A  modification  lo  the  database  immediately 
overwrites  cached  information.  The  copy  on  disk  is  not.  however, 
overwrite!!.  Rather,  tut  audit  trail  of  changes  is  maintained  in  lire 
database  by  appending  a  limcslampcd  entry  indicating  the  change  and  llte 


identity  of  Ihe  user  making  Ihe  modifi'ation.  On  startup  Ihe 
authentication  server  initialises  its  cache  by  reading  the  database 
sequentially.  Later  changes  thus  override  earlier  ones.  An  offline 
program  has  to  be  run  periodically  to  compact  the  database. 

Tile  key  used  by  tile  authentication  server  for  encrypting  sccrel  tokens 
lias  to  be  known  to  all  the  Vice  file  servers.  This  key  should  be  changed 
periodically  if  an  Andrew  silc  is  serious  aboul  security.  The  Vice  file 
servers  remember  the  two  most  recent  such  keys  ar.d  try  them  one  after 
Ihe  other  when  decrypting  a  secret  token.  This  allnws  uncxpiicd  tokens 
to  be  used  even  if  Ihe  authentication  server  lias  changed  keys.  At  present 
key  distribution  is  manual;  this  should  be  automated  in  Ihe  futute. 

For  robustness,  there  is  an  instance  of  the  authentication  server  running 
on  each  Vice  file  server.  These  are  slaves  and  respond  only  to  queries. 
Only  one  server,  the  master,  accepts  updates.  Changes  are  propagated  lo 
slaves  over  the  secure  communication  channel  referred  lo  in  Section  5. 
For  this  specific  application,  notiuiiiform  propagation  speed  and  the 
temporary  inconsistencies  that  may  result  do  not  pose  a  serious  problem. 
For  further  robustness,  cacti  instance  of  the  authentication  server  has  an 
associated  watchdog  Unix  process  that  resorts  it  in  the  event  of  a  crash. 

Each  server  instance  has  a  log  file  in  which  authentication  failures  and 
unsuccessful  attempts  lo  update  die  password  database  are  recorded. 
Figure  5  shows  tut  cxccrpl  from  sucli  a  log.  It  would  not  be  difficult  to 
provide  a  more  sophisticated  and  timely  warning  mechanism  for  system 
personnel  if  suspicious  events  arc  observed  by  authentication  servers. 

6.  Protection  in  Vice 

As  die  custodian  of  shared  information  in  Andrew.  Vice  enforces  the 
protection  policies  specifed  by  users.  The  scale,  character  and  periodic 
change  in  llte  composition  of  Ihe  user  community  in  a  university 
necessitate  a  protection  mechanism  dial  is  simple  to  use  yet  allows 
complex  policies  lo  lie  expressed.  A  further  consequence  of  these  factors 
is  that  revocation  of  access  privileges  is  an  important  and  common 
operation,  in  ihe  light  of  these  considerations  we  opted  to  use  an  Aeeess 
List  mechanism  in  Andrew.  The  next  three  sections  describe  hove  access 
lists  are  implemented,  how  they  are  used  lor  file  protection,  anil  how 
Vice  represents  and  maintains  information  on  llte  protection  domain. 

6.1.  Access  Lists 

Tile  access  list  mechanism  is  implemented  as  a  package  available  to  any 
service  in  Vice,  though  only  the  distributed  file  system  currently  uses  it. 
Art  entry  in  an  access  list  maps  a  member  of  the  protection  domain  into  a 
set  of  Rights.  which  are  merely  bit  positions  in  a  32-bit  integer  mask. 
Tltc  interpretation  of  rights  is  specific  lo  each  Vice  service.  The  total 
rights  possessed  b\  t  user  on  tul  object  is  llte  union  of  all  the  rights 
possessed  by  the  m  aibcrs  of  his  CPS.  In  oilier  words,  he  possesses  the 
maximal  rights  o  ectivcly  possessed  by  himself  and  all  the  groups  ol 
which  he  is  a  direct  or  indirect  member. 

An  access  list  is  actually  composed  of  two  sublists:  a  iisl  of  Positive 
Rights  and  a  list  of  Negative  Rights.  An  entry  in  a  positive  lights  list 
indicates  possession  of  a  set  of  rights.  In  a  negative  rights  list,  il 
indicates  denial  of  those  rights,  in  case  of  conllict.  denial  overrides 
possession. 

Negative  rights  are  primarily  a  means  of  rapidly  and  selectively  revoking 
access  to  sensitive  objects.  Although  such  revocation  is  more  properly 
done  by  changes  to  the  prolection  domain,  ihe  changes  may  take  time  to 
propagate  in  a  large  distributed  system.  Negative  rights  can  reduce  the 
window  of  vulnerability,  since  changes  to  access  lisls  are  effeclive 
immediately.  As  an  example,  if  it  is  discovered  (tint  a  member  of  a  large 
group  is  misusing  his  privileges,  he  can  be  immediately  given  negative 
rights  on  objects  used  by  the  group.  He  can  also  be  deleted  from  all 
groups  Hull  may  directly  or  indirectly  give  him  rights  on  those  objects. 
After  the  membership  changes  are  effeclive  at  all  Vice  servers,  he  can  be 
removed  from  Ihe  negative  rights  lists.  Negative  rights  thus  decouple  the 
problems  of  rapid  revocalion  and  propagation  of  information  in  a  large 
distributed  system.  They  can  also  be  used  to  specify  protection  policies 
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of  the  form  ■'Grant  rights  R  to  all  members  of  group  G.  except  user 
U."  Rabin  and  Tygij-,  in  their  recent  work  on  ITOSS  (21  i,  independently 
confirm  the  advantages  of  providing  negative  privileges. 

The  algorithm  executed  during  an  access  list  check  is  quite  efficient. 
Suppose  A  is  an  arbitrary  access  list  and  C  is  the  CPS  of  U.  The  entries 
in  A  and  C  are  maintained  in  sorted  ordet.  The  rights  possessed  by  V  are 
determined  as  follows: 

1  Let  M  and  N  he  rights  masks,  initially  empty 
For  each  clement  of  C,  if  (here  is  an  entry  in  the  positive 
rights  list  of  A.  indusive-OR  M  with  the  rights  portion  of 
the  entry. 

•V  For  cacti  element  of  C,  if  there  is  an  entry  in  die  negative 
rights  list  of  /l.  indusive-OR  N  with  the  rights  portion  of 
the  entry. 

4.  Bitwise  subtract  N  from  M. 

5.  M  now  specifies  die  rights  that  V  possesses. 

Profiling  of  the  Vice  servers  in  actual  use  confirms  that  die  overheads 
due  to  access  list  checks  are  negligible. 

6.2.  l  ilt1 I’nilecliott 

Vice  associates  an  access  list  with  eacli  directory.  The  access  list  applies 
to  all  files  in  the  directory,  thus  giving  them  uniform  protection  status. 
The  primary  reason  for  this  design  decision  is  conceptual  simplicity. 
Users  have,  at  all  times,  a  rough  mental  picture  of  the  protection  state  of 
the  files  they  access.  In  a  large  system,  the  reduction  in  state  obtained  by 
associating  protection  with  directories  rather  than  files  is  considerable. 
A  secondary  benefit  is  the  reduced  storage  overhead  on  servers.  Usage 
experience  in  Andrew  has  proved  that  this  is  an  excellent  compromise 
between  providing  protection  at  fine  granularity  and  retaining  conceptual 
simplicity.  In  the  rare  instances  where  a  file  needs  to  have  a  different 
protection  status  from  other  files  in  its  directory,  we  place  that  file  in  a 
separate  directory  with  appropriate  protection  and  put  a  symbolic  link  to 
il  in  the  original  directory. 

Seven  kinds  of  rights  are  associated  with  a  directory: 

read  (r)  read  any  file 

write  tw)  write  any  file 

look u/i  (1)  lookup  status  of  any  file 

Insert  ti)  insert  a  new  file  in  lliis  directory  (only  if  it  does  not 

already  exist).  This  is  particularly  useful  in 
implementing  mailboxes. 

delete  (d)  delete  any  existing  file 

administer  (a)  modify  the  access  list  of  (his  directory 

In ek  (k)  lock  any  file.  This  has  turned  out  not  to  he  a 

particularly  useful  right,  but  continues  to  be 
supported  for  historical  reasons. 

TItc  three  most  commonly  used  combinations  of  righis  are  i  l.  for  read 
access,  rwiidk  for  wide  access,  and  rwlidka  for  complete  access.  Figure 
0  shows  an  example  of  the  access  list  on  a  Vice  directory.  Modifications 
lo  access  lists  take  effect  immediately. 

Certain  privileges  commonly  found  in  timesharing  systems  do  not  make 
sense  in  the  context  of  Andrew.  Execute-only  nrivilcgc.  for  example,  is 
noi  a  right  that  Vice  can  enforce  since  program  execution  is  done  by 
Virtue.  Revocation  of  read  rights  is  another  area  where  Vice  can  do  little 
since  Virtue  caches  files.  At  best  il  can  ensure  that  new  versions  of  a  file 
are  not  readable  by  the  user  whose  access  is  revoked. 

6.3.  Protection  Domain  Rcprcsenlation 

Protection  domain  information  is  maintained  in  a  database  that  is 
rephcaled  at  each  Vice  file  setver.  The  database  consists  of  a  data  file  on 
disk  and  an  index  file  that  is  cached  in  its  entirety  in  virtual  memory. 
The  index  file  enables  id-to-naitic  translations  in  constant  time,  and 
name-to-id  translations  in  logarithmic  lime.  For  each  entry,  the  index 
also  contains  the  offset  in  the  data  file  where  the  first  byte  of  information 
about  the  corresponding  user  or  group  is  stored.  A  typical  lookup  of  the 
database  by  user  or  group  name  involves  a  search  to  find  the  id,  followed 
by  a  seek  operation  and  a  read  operation  on  the  data  file. 


Each  entry  in  the  database  corresponds  to  a  single  user  or  group.  It 
consists  ol  a  name  and  an  id  tollowcd  by  three  lists  specifying 
membership  information.  The  first  list  specifics  the  groups  to  which  that 
user  or  group  directly  belongs,  while  the  second  list  is  the  precomputed 
CPS.  For  a  user,  the  third  list  enumerates  the  groups  owned  by  the  user; 
for  a  <roup,  it  is  the  list  of  users  or  groups  who  are  its  direct  members. 
Each  entry  also  lias  an  associated  access  list,  that  is  unused  at  the  present 
time.  We  intend  to  allow  users  to  directly  manipulate  the  database  via  a 
protection  server.  The  access  lists  will  then  control  the  examination  and 
modification  of  group  membership.  Figure  7  shows  an  excerpl  of  the 
database. 

When  Venus  makes  a  secure  RPC  connection  on  behalf  of  a  user,  the  file 
server  caches  the  CPS  of  the  user  in  virtual  memory  and  uses  it  on  access 
list  checks.  At  present,  changes  to  the  protection  domain  do  not  affect 
the  cached  copy  until  the  RPC  connection  is  ierminated.  It  would  be 
iclnlively  simple  lo  modify  the  server  to  invalidate  cached  CPS  copies 
whenever  the  protection  domain  changes. 

At  present,  changes  lo  the  protection  domain  are  manually  performed  at  a 
central  site  in  Vice.  Utilities  are  available  to  simplify  the  creation  or 
deletion  of  a  user  or  to  modify  the  membership  of  a  group.  These 
utilities  also  precompute  the  CPS  by  transitive  closure  and  construct  the 
index  file.  Modifications  performed  at  the  central  site  are 
asynchronously  propagated  lo  all  other  Vice  sites  via  the  secure 
communication  channel  mentioned  in  Section  3.  In  our  experience,  the 
minor  temporary  inconsistencies  that  occasionally  arise  due  to  varying 
propagation  speeds  have  not  significantly  affected  the  usability  of  the 
system. 

7.  Protection  in  Virtue 

As  a  nnilti-uscr  Unix  system,  Virtue  enforces  the  usual  firewalls  belween 
multiple  users  concurrently  using  a  workstation.  In  addition,  its  role  in 
Andrew  places  oilier  respousibilites  related  lo  security  on  it: 

•  It  emulates  Unix  semantics  for  Vice  files. 

•  It  ensures  that  caching  is  consistent  with  protection  in  Vice. 

•  It  allows  owners  full  control  over  their  workstations,  w  ithout 
compromising  Vice  security. 

•  It  provides  user  and  program  interfaces  for  explicitly  using 
the  security  mechanisms  of  Vice. 

The  next  four  sections  describe  these  functions  in  detail. 

7.1.  Unix  ICiiHilatioh 

Virtue  provides  strict  Unix  protection  semantics  for  local  files  and  a 
close  approximation  for  Vice  files.  Each  Unix  file  has  9  Made  bits 
associated  with  it.  These  mode  bits  arc,  in  effect,  a  3-entiy  access  list 
specifying  whether  or  not  the  owner  of  the  file,  a  single  specific  group  of 
users,  and  everyone  else  cun  read,  write  or  execute  the  file. 

Venus  does  the  emulation  of  Unix  protection  for  Vice  files.  In  a 
prototype  implementation  of  Andrew,  the  mode  hits  in  a  file  were 
derived  from  the  access  list  of  ns  d. rectory  and  could  nol  be  changed  by 
applications.  Unfortunately  a  few  applications,  such  as  version  control 
software,  encode  state  in  the  mode  bits.  In  addition,  our  users  expressed 
a  desire  to  be  able  lo  prevent  themselves  from  accidentally  deleting 
critical  files  in  a  directory.  Wc  have  therefore  evolved  a  scheme  in 
which  the  Vice  access  list  check  described  in  Section  6.1  performs  the 
real  enforcement  of  protection  and,  in  addition,  the  three  owner  hits  of 
the  file  mode  indicate  readability,  wrilabilily  or  execulability.  These 
bits,  which  now  indicate  what  can  be  done  lo  the  file  rather  than  who  can 
do  il.  arc  set  and  examined  by  Venus  but  ignored  by  Vice.  For 
directories,  the  mode  bits  are  completely  ignored.  The  directory  listing 
program,  LS.  has  been  modified  in  Andrew  to  omit  mode  bits  for 
directories  and  show  only  die  owner  bits  for  files.  Figure  8  shows  an 
example  of  a  directory  listing  in  Vice. 

Since  the  group  mechanisms  of  Vice  and  standard  Unix  are  incompatible 
Venus  does  not  emulate  Unix  group  protection  semantics.  Our 
experience  indicates  that  no  real  applications  have  been  affected  by  ibis.  ’ 
From  die  point  of  view  of  an  application  all  Vice  files  belong  to  a  single 
Unix  group. 
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7.2.  CiidiihK  Protection  Information 

Although  ignorant  e."  the  Vice  group  mechanism.  Venus  caches 
protection  information.  When  a  directory  is  cached  on  behalf  of  a  usei , 
Vice  includes  rights  information  for  the  user  and  SysleniiAnyUser. 
Future  requests  are  checked  by  Venus  without  contacting  Vice.  If  a 
different  user  on  that  workstation  wisties  to  access  the  same  directory, 
and  the  rights  foi  Systeni:AnyUscr  are  inadequate.  Venus  explicitly 
obtains  his  rights  from  Vice.  Protection  information  can  he  cached  lor  a 
small  number  of  distinct  users  on  each  directory.  If  there  are  more  users 
on  a  workstation  the  protection  checks  will  be  functionally  accurate,  but 
will  take  longer  because  of  ineffective  caching.  Vice  notifies  Venus 
whenever  die  protection  on  a  cached  directory  changes. 

Caching  interacts  with  Unix  semantics  in  a  counter-intuitive  manner.  In 
Unix,  protection  failures  can  only  occur  when  opening  a  file.  In  Andrew, 
a  protection  failure  can  occur  when  closing  a  file  if  the  protection  on  one 
of  tltc  directories  in  its  path  was  changed  while  the  file  was  open.  There 
is  no  simple  solution  to  this  problem  because  Vice  cannot  delegate  the 
responsibility  of  checking  access  on  store  operations.  It  cannot  trust  tltc 
access  cheek  that  Venus  pcrfoims  when  opening  a  cached  file. 

This  difference  from  Unix  semantics  affects  a  number  of  common  Unix 
applications  that  do  not  expect  the  close  operation  to  fail,  and  hence  do 
not  check  return  codes  from  it.  In  rare  instances,  the  user  of  such  an 
application  may  be  unaware  that  one  or  more  files  were  not  stored  in 
Vice  because  of  a  protection  violation.  Wc  do  try  to  inform  users  of  the 
problem  by  printing  a  message  on  die  workstation  console.  However, 
using  the  console  as  an  oul-of-bantl  notification  mechanism  does  not  help 
in  situations  where  dierc  is  no  user  to  act  upon  the  message.  The  only 
robust  solution  to  this  insidious  failure  mode  is  to  modify  the 
applications  to  check  return  codes. 

7.3.  .Superuser  I’  ivileges 

Certain  sensitive  operational  procedures  in  Unix  can  only  be  perforated 
by  the  pseudo-user  “root”.  Workstation  owners  need  to  become  tool  on 
occasion  to  perform  these  procedures.  As  a  result,  tool  is  logically 
equivalent  to  a  group  account  as  discussed  in  Section  4.  An  RPC 
connection  on  behalf  of  root  provides  no  knowledge  about  which  actual 
user  il  corresponds  to. 

A  further  complication  is  dial  the  initialisation  of  a  workstation  causes  a 
number  of  standard  processes  belonging  lo  root  to  come  into  existence 
automatically.  Since  there  may  be  no  users  logged  in,  Venus  may  not 
have  tokens  with  which  lo  make  authenticated  connections  for  these 
processes.-'  We  address  these  problems  by  treating  root  specially  and 
granting  il  the  same  default  access  privileges  in  Vice  as 
System:AnyUser.  RPC  connections  made  on  behalf  ol  root  are 
urnmthenticaied  and  insecure.  Usage  experience  indicates  that  this 
provides  a  good  compromise  between  security  and  usability. 

The  Sctuitl  mechanism  in  Unix  effectively  provides  amplification  of 
rights  1 1 3 1 .  When  a  file  marked  seluid  is  executed,  il  acquires  the  access 
privileges  of  the  owner  of  the  file  radter  than  the  user  executing  the  file. 
The  interpretation  and  enforcement  of  the  seluid  properly  is  done  bv 
Virtue,  but  Vice  requires  authentication  tokens  for  tile  owner  of  the 
program  being  tun  seluid,  Since  die  tokens  will  not  be  available  except 
in  the  unlikely  case  of  the  owner  of  die  file  being  logged  m  to  the 
workstation,  Andrew  cannot  support  die  setuid  mechanism  in  its  general 
form.  However,  many  useful  system  utilities  on  workstations  are  owned 
by  root  and  tun  seluid.  Since  root  has  only  SystcnitAnyUser  privileges 
on  Vice  files,  and  since  RPC  connections  for  root  do  not  require  tokens, 
wc  are  able  to  support  seluid  in  this  limited  form. 

If  naively  implemented,  seluid  programs  owned  by  root  would  make 
Trojan  liotses  trivial.  A  user  could  become  rool  on  his  workstation,  store 
a  Trojan  horse  program  in  Vice  and  mark  it  setuid.  If  this  program  were 
run  by  any  other  user,  it  would  be  able  to  compromise  ids  workstation. 


s Automatic  lugging  in  of  toot  would  require  the  pinowottl  to  he  Mount  in  the  cleiii  ■>!> 
workstation*,  u  cceurity  risk  wc  were  unwilling  to  assume. 


To  guard  against  this,  we  define  a  special  Vice  user  “stem.’’  No  one  can 
be  authenticated  as  stem,  but  a  system  administrator  can  n.ake  stem  the 
owner  of  ;t  file.  When  Venus  caches  a  setuid  file  owned  by  stem,  it 
translates  the  owner  to  root  and  honours  tltc  setuid  property,  If  the  file  is 
not  owned  by  stem,  the  setuid  property  is  ignored. 

7.4.  Vice  Interface 

Virtue  provides  a  number  of  programs  to  allow  users  lo  use  the  security 
mechanisms  of  Vice,  fs  is  a  program  to  allow  users  to  set  and  examine 
Vice  access  lists.  LOGIN,  LOG.  and  SU  are  modified  versions  of  standard 
Unix  programs.  They  prompt  for  a  password,  contact  the  authentication 
server,  obtain  tokens  and  pass  them  to  Venus.  A  modified  version  of  the 
Unix  PASSWD  program  allows  users  to  change  their  passwoids  by 
contacting  the  authentication  server. 

For  oilier  applications.  Virtue  provides  a  library  of  routines  to  get,  set 
and  delete  tokens  stored  by  Venus.  An  important  user  of  these  routines 
is  the  Andrew  version  of  the  standard  Unix  program  RSH  that  allows  a 
user  to  execute  a  program  on  a  remote  workstation.  Another  important 
user  is  REM.  a  program  that  makes  idle  workstations  available  for  remote 
use  (201.  Both  these  programs  extract  tokens  from  the  workstation  a  user 
is  at,  and  passes  them  to  the  remote  Venus  so  that  it  can  access  Vice  files 
on  bclmlf  of  the  user.  Since  tire  clear  and  secret  tokens  are  sent  in  the 
clear  by  these  programs,  they  violate  the  security  assumptions  of  Section 
3.  Nevertheless,  these  programs  are  popular  in  our  user  community. 

There  arc  occasions  when  a  user  may  wish  to  voluntarily  restrict  his 
rights.  For  example,  he  may  wish  to  run  a  program  being  debugged  in  an 
environment  dial  will  not  allow  it  to  modify  critical  files.  Virtue  allows  a 
user  to  temporarily  disable  Itis  membership  in  one  or  more  groups.  Sueli 
it  group  may  he  reenabled  at  a  later  time.  We  also  intend  to  allow  groups 
lo  be  disabled  by  default,  but  this  is  nol  implemented  at  the  present  lime 
except  for  the  special  group  SyslenitAdministrators. 

To  implement  this  temporary  disabling  of  membership.  Virtue  associates 
a  unique  integer  called  a  Process  Access  Group  (PAG)  with  eaclt 
process.  When  a  piocess  forks,  its  eltild  inherits  the  PAG.  Venus 
associates  secure  RPC  connections  lo  a  server  with  (user,  PAG)  pairs. 
Usually  all  die  processes  of  a  user  have  a  single  PAG.  If  a  user  disables 
lii.s  membership  of  a  group,  the  process  in  which  the  disabling  command 
was  issued  acquires  a  new  PAG.  Each  lime  another  server  is  contacted 
on  behalf  of  the  new  (user.  PAG)  pair.  Venus  makes  a  secure  RPC 
connection  and  requests  (lie  server  to  disable  membership  in  the  specified 
groups.  The  server  constructs  a  reduced  CPS  for  that  connection  and 
uses  it  on  access  list  checks.  PAGs  also  change  when  a  LOG  or  SO 
command  is  executed. 


8.  Rest iu  rev  Usage 

Tltc  absence  of  a  local  point  for  allocation  of  resources  makes  resource 
control  difficult  in  a  distributed  system.  Processes  in  a  typical 
timesharing  system  are  constrained  in  the  rate  at  which  they  can  consume 
resources  by  the  CPU  scheduling  algorithm.  No  such  throttling  agent 
exists  in  a  typical  distributed  system.  Another  significant  difference  is 
that  a  process  in  a  timesharing  system  lias  to  be  authenticated  before  it 
can  consume  appreciable  amounts  of  resources.  In  contrast,  each 
Andrew  workstation  can  be  modified  to  anonymously  consume  network 
bandwidth  and  server  CPU  cycles. 

As  discussed  in  Section  3.  Andrew  is  nol  designed  to  he  immune  to 
security  violations  by  denial  of  resources.  However,  it  does  provide 
control  over  some  ol  rite  resources.  The  major  resources  in  Andrew  are: 

•  network  bandwidth. 

•  server  disk  storage  and  CPU  cycles, 

•  workstation  disk  storage  and  CPU  cycles. 

In  (he  next  three  sections  we  examine  how  Andrew  treats  these 
resources. 

8.1.  Network  Bandwidth 

Since  Andrew  does  not  provide  mechanisms  to  control  use  of  network 
bandwidth,  responsible  use  of  die  network  is  primarily  achieved  by  peer 
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pressure  mid  social  mores  of  die  user  community.  Blatant  misuse,  such 
as  by  flooding  with  packets,  is  relatively  easy  to  detect.  But  it  is  laud  to 
detect  subtle  misuse.  l7or  example,  a  malicious  user  can  generate  a  level 
of  traffic  that  degrades  performance  but  does  not  bring  useful  network 
activity  to  a  standstill.  Or  he  can  use  multiple  widely-separated  public 
workstations  to  generate  high  volumes  of  traffic.  Identifying  the  user  can 
be  particularly  difficult  because  he  can  modify  workstations  to  generate 
packets  with  arbitrary  source  addresses. 

In  our  experience,  network-related  problems  have  not  been  due  to 
malicious  aciivity.  Occasionally  we  obsetve  high  network  ulilisalion  and 
poor  file  transfer  rates  on  segments  of  the  network  Ural  support  non- 
Andrew  diskless  workstations.  The  problem  lias  not  proved  serious 
enough  yet  to  warrant  special  attention.  In  one  memorable  instance,  a 
bug  in  the  low-level  network  code  on  workstations  was  triggered  by  a 
malformed  broadcast  packet  generated  by  a  non-malicious  user  during 
debugging.  The  bug  affected  every  workstation  in  the  cnviionmem  and 
effectively  halted  all  of  them. 

8.2.  Server  Usage 

Because  of  llte  long-term,  shared  nature  of  the  resource,  we  fell  it 
important  to  be  able  to  control  disk  usage  on  servers.  An  Andrew  system 
administrator  can  specify  a  storage  quota  for  the  Vice  t  iles  of  a  user.  The 
quota  is  actually  placed  on  a  Volume ,  an  encapsulation  of  a  small  subtree 
of  tire  Vice  file  space  [27).  ami  can  be  changed  with  ease. 

When  storing  a  file  cn  behalf  of  a  user,  a  server  will  abort  a  store 
operation  if  his  quoia  is  exceeded.  This  can  cause  a  problem  similar  to 
the  one  described  in  .Section  7.1;  tut  application  program  that  does  not 
check  (he  return  codes  front  a  close  operation  will  not  report  a  failure 
caused  by  the  quota  being  exceeded.  Bui  our  users  and  system  personnel 
consider  server  disk  storage  an  important  enough  resource  that  they  have 
tolerated  this  problem. 

A  minor  exposure  arises  from  (lie  manner  in  which  electronic  mail  is 
implemented  in  Andrew.  Each  user  has  a  mailbox  directory  on  which 
SysloimAnyUser  has  insert  rights.  Mail  is  delivered  by  storing  a  file  in 
Ibis  diteclory.  A  malicious  user  could  exhaust  the  quota  of  another  user 
by  sending  him  large  quantities  of  junk  mail.  In  practice,  this  has  no! 
proved  to  be  u  problem. 

Allhough  a  user  caiinul  exeeule  a  program  on  a  server.  Ids  Venus  ean 
consume  server  CPU  cycles  in  file  system  operations.  Excessive 
demands  on  a  server  are  a  form  of  resource  denial  to  other  users.  Al 
present.  Vice  does  not  constrain  the  amount  of  server  CPU  cycles  a  uset 
ean  utilise.  It  could  do  so,  if  necessary,  since  user  requests  come  in  on 
distinct  UPC  connections. 

8..1.  Workstation  Usage 

Andrew  does  not  restrict  the  amount  cf  space  used  by  local  files  on 
workstations.  For  cached  Vice  files.  Venus  employs  an  LRU  algorithm 
to  limit  disk  usage  below  a  value  specified  al  initialisation.  The 
algorithm  is  not  infallible  because  read  and  write  operations  are  nol 
intercepted  by  Venus.  It  is  possible  for  a  program  lo  open  a  short  file 
and  Ihcn  append  a  large  amount  of  data  thereby  exceeding  the  cache 
limit.  In  practice  ibis  has  rarely  been  a  problem. 

Since  a  workstation  can  be  privately  owned,  il  would  seem  inappropriate 
for  Andrew  to  constrain  the  use  of  its  CPU  cycles.  However,  the 
problem  has  proved  more  complex  than  we  anticipated.  The  primary 
source  of  difficulty  is  the  fact  dial  each  workstation  is  a  full-fledged  Unix 
system.  Hence  il  is  possible  to  remotely  access  one  workstation  from 
another  via  standard  Unix  programs  such  as  TELNET  and  HSU.  Since  the 
Vice  file  space  is  identical  at  nil  workstations,  it  is  particularly  easy  for  a 
user  to  use  my  workstation  as  his  own.  Such  convenience  was,  of 
course,  a  fundamental  motivation  for  the  distributed  file  system. 

I  Inlnnunntely.  an  individual  al  a  workstation  peiccives  the  attempt  to  use 
its  cycles  try  another  user  as  a  security  violation.  This  perception  is 
particularly  strong  il  the  first  user  is  at  the  console  of  the  workstation. 
Totally  disabling  the  network  daemons  dial  allow  remote  access  is  nol  a 


viable  solution  for  two  reasons.  First,  system  personnel  sometimes  need 
to  remotely  access  workstations  for  troubleshooting.  Second,  an  ownci 
may  wish  to  access  his  workstation  from  home.  Our  modem  access 
facilities  require  die  network  daemons  to  be  present. 

We  have  evolved  a  mechanism  whereby  TELNET  access  lo  a  workstation 
can  be  restricted  to  n  list  of  users  stored  in  the  local  file  system  of  that 
workstalion.  This  restriction  is,  however,  stronger  than  what  most  users 
desire.  When  he  is  not  using  bis  workstation,  a  user  is  usually  amenable 
to  others  using  it.  Il  is  also  unacceptable  for  public  workstations, 
because  every  Andrew  user  should  be  able  to  use  them.  At  die  present 
time  we  do  not  have  a  completely  satisfactory  solution  to  this  resource 
problem.  The  REM  system,  mentioned  in  Section  7.4,  allows  a  user  lo 
specify  the  conditions  lira!  must  be  satisfied  for  his  workstation  to 
become  available  for  remote  use.  Although  satisfactory  to  a  logged-in 
user.  Uiis  approach  is  harsh  on  the  REM  user  who  is  in  constant  danger  of 
having  Iris  computation  aborted  at  the  remote  she.  A  full-fledged  Sutler 
mechanism  |7],  that  migrates  remote  users  rather  than  aborting  them 
would  be  a  more  acceptable  alternative. 

The  problem  of  controlling  workstation  CPU  usage  will  become  acute  as 
Andrew  grows.  The  huge  pool  of  idle  workstations  available  lor  parallel 
computation,  and  die  development  of  applications  that  exploit  such 
parallelism  will  make  remote  use  even  more  attractive  m  future. 

Kneryption 

Security  ill  Andrew  is  predicated  on  lire  ability  of  clients  and  servers  to 
perform  encryption  for  authentication  and  secure  communication.  The 
design  and  implementation  of  die  encryption  algorithm  has  to  salisly 
certain  properties: 

•  it  must  be  difficult  to  break,  given  the  computational 
rcsouiees  available  to  a  malicious  individual  in  a  typical 
Andrew  environment. 

•  It  must  be  fast  enough  that  neither  die  latency  perceived  by 
clients  nor  lire  throughput  of  servers  be  noticeably  degraded. 

•  h  must  be  cheap  enough  drat  il  does  nol  appreciably  increase 
the  cost  of  a  workstation  owned  by  an  individual , 

Based  on  considerations  of  strength  and  standardization,  we  have  chosen 
lire  Onto  Enervation  Standard  (DES)  1  i  7 1  published  oy  the  National 
Bureau  of  Standards  as  the  preferred  encryption  algorithm  in  Andrew. 
Since  die  encryption  algorithm  is  a  parameter  to  our  RPC  mechanism,  ii 
is  possible  lo  use  oilier  algorithms.  We  believe,  however,  dial 
standardising  on  DES  is  appropriate  in  our  environment.  This  algorithm 
has  been  publicly  scrulinizcd  for  many  years  and  although  concerns  have 
been  expressed  about  its  strength  |Xj,  we  leel  dial  DF.S  is  adequate  lor 
the  level  of  security  we  require. 

Al  the  present  time  the  latency  for  a  simple  interaction  between  a  diem 
and  server  is  about  20  to  25  milliseconds,  and  the  file  transfer  rate  is 
about  50  to  70  kbytes  per  second.  We  expect  these  numbers  to  improve 
over  time,  as  Venus.  Vice  and  tile  routers  ill  the  nolwutk  are  improved. 
The  fastest  software  implementation  of  DES  dial  we  ate  aware  of  runs  at 
less  than  5  kbytes  per  second  on  a  typical  workstation.  Software 
encryption  would  therefore  be  an  intolerable  performance  bottleneck  in 
our  system;  hardware  is  essential. 

Encryption  devices  embedded  in  low-level  communication  hardware 
have  been  available  for  some  time  in  mainframes.  In  many  cases  suclt 
devices  provide  secure  machine  to  machine  communication  over  an 
insecure  link,  bul  are  nol  accessible  to  higher  level  software.  Andrew 
depends  on  cnd-to-eml  encryption  where  the  ends  are  user  level 
processes  on  workstations  and  Vice  servers.  Since  every  connection  lias 
a  distinct  key.  otdy  RPC  software  can  determine  the  key  lo  use  in 
encrypting  a  packet.  Transparent  embedding  of  encryption  capability  at 
a  low  level  is  therefore  not  useful  in  Andrew. 

Although  u  number  of  VLSI  chips  for  DES  arc  available  [2, 29], 
integration  of  such  chips  into  workstation  peripherals  is  not  common.  A 
commercially  available  device  for  die  IBM  PC- AT  [1 1,  I2|  could  be 
used  in  our  IBM  RT-PC  workstations,  but  its  performance  of  50  kbytes 
per  second  is  barely  adequate.  We  have  therefore  built  a  prototype 
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device  |6]  for  (he  IBM  RT-PCs  using  the  AMD  9568  chip.  Based  on  our 
parts  cost  and  labour,  we  estimate  that  a  commercial  version  of  this 
device,  produced  in  quantity,  would  cost  an  end  user  between  $500  and 
$800.  As  perceived  by  a  user-level  process,  the  time  to  encrypt  N  bytes 
using  the  device  is  N  *  k  +  C,  where  k  is  4  microseconds  per  byte,  and  C 
is  470  microseconds.  The  overhead  of  the  device  is  thus  under  a 
millisecond  for  a  small  packet  and  the  asymptotic  encryption  rate  is 
about  200  kbytes  per  second,  We  are  currently  redesigning  the  device  to 
reduce  k  in  die  above  expression  to  about  0.6  microseconds  per  byte, 
yielding  an  asymptotic  encryption  rate  of  over  1  Mbyte  per  second.  At 
tlic  present  time,  we  do  not  have  encryption  devices  for  the  Sun  and 
Microvax  workstations  in  our  environment. 

A  difficult  nontechnical  problem  is  justifying  the  cost  of  encryption 
hardware  to  management  and  users.  Unlike  extra  memory,  processor 
speed,  or  graphics  capability,  encryption  devices  do  not  provide  tangible 
benefits  to  users.  The  importance  of  security  is  often  perceived  only 
after  it  is  too  late.  At  present,  encryption  hardware  is  viewed  as  an 
expensive  frill.  We  believe,  however,  that  the  awareness  that  encryption 
is  indispensable  for  security  in  Andrew  will  eventually  make  it  possible 
for  every  client  and  server  to  incorporate  a  hardware  encryption  device. 

In  the  interim,  while  the  logistic  and  economic  aspects  of  obtaining 
encryption  hardware  are  being  addressed.  Andrew  uses  exclusive-or 
encryption  in  soitware.  Although  it  is  trivially  broken,  we  fell  it  worth 
our  while  to  use  it  for  two  reasons.  First,  it  ex  idses  all  paths  in  our 
code  pertaining  to  security,  and  allows  us  to  validate  out  implementation. 
Second,  although  a  weak  algorithm,  il  does  require  a  user  to  perform  an 
explicit  action  to  violate  security  by  decrypting  data.  Merely  observing  a 
sensitive  packet  on  the  network  by  accident  will  not  divulge  its  contents. 

10.  Other  Security  Issues 

We  now  consider  tlirec  diverse  questions  from  the  viewpoint  of  security 
in  Andrew: 

•  How  do  low-power  personal  computers  access  Vice  files? 

•  Can  diskless  workstations  be  made  secure? 

•  Is  decentralised  administration  of  Andrew  possible? 

Sections  1(1.1  to  10  3  examine  these  questions.  In  focusing  only  on 
security  our  discussion  ignores  many  broader  issues  and  implementation 
details. 

10.1.  PC  Server 

Personal  computers  [PC's)  sucli  as  the  IBM  PC  and  Apple  Macintosh 
differ  from  Andrew  workstations  in  that  they  do  not  run  Unix  and  often 
do  not  possess  a  local  disk.  They  tire  thus  not  capable  of  being  full- 
fledged  clients  of  the  Andrew  File  System.  Since  a  significant  number  of 
Andrew  uses  also  use  PCs.  wc  have  developed  a  mechanism  (hat 
enables  PCs  lo  access  Vice  files. 

Vice  access  from  a  PC  is  mediated  by  a  server  called  PCServer,  that 
makes  a  Unix  file  system  transparently  accessible  from  a  PC.  Since  Vice 
files  are  pari  of  the  Unix  file  name  space  of  an  Andrew  workstation, 
PCServcr  automatically  makes  them  accessible  from  PCs.  The  primary 
advantage  of  this  decoupling  is  that  it  allows  the  Andrew  File  System  to 
exploit  techniques  essential  to  scalability,  without  distorting  its  design  lo 
accommodate  machines  of  inadequate  hardware  capability. 

Communication  between  a  PC  and  PCServcr  uses  a  protocol  distinct 
from  that  used  if  the  Andrew  file  system.  The  protocol  supports 
encryption  using  a  key  that  is  randomly  generated  and  sent  in  the  clear 
when  a  ciietil-scrver  connection  is  established.  It  does  not  incorporate 
the  8-way  BIND  handshake  described  in  Section  5.1,  but  does  support  a 
weaker  form  of  authentication.  The  workstation  running  PCServer  also 
runs  an  authenticator  process  called  Guardian.  When  a  PC  user  needs  lo 
access  Vice  files,  he  supplies  his  Andrew  user  id  and  password.  These 
are  transmitted  to  Guardian,  which  contacts  the  Andrew  authentication 
server  and  obtains  authentication  tokens  in  a  manner  Identical  to  LOOIN, 
as  described  in  Section  5.2.  The  password  and  tokens  are  logically  sent 
in  (he  dear,  but  are  encrypted  with  a  fixed  key  known  to  Guardian  and 
PCServer.  Although  this  is  nol  secure,  it  does  provide  a  modicum  of 


privacy.  Guardiun  hands  these  tokens  tc  Venus  and  then  forks  a 
dedicated  Unix  PCServer  process  on  behalf  of  the  user.  This  process 
acts  as  the  surrogate  of  the  PC  user  and  services  file  requests  from  his 
PC. 

From  the  point  of  Venus,  it  appears  as  if  the  PC  user  had  actually  logged 
in  at  the  workstation  running  PCServer.  Enforcement  of  protection  for 
Vice  files  is  performed  exactly  as  described  in  Section  6.2,  The  main 
security  exposure  in  using  PCServer  is  the  information  sent  in  the  clear 
between  the  PC  and  Guardian  during  the  establishment  of  a  session. 

10.2.  Diskless  Workstations 

Operating  workstations  without  local  disks  has  been  shown  to  be  a  viable 
and  cosi-effective  mode  of  operation  [161.  However,  tile  impact  of 
diskless  operation  on  security  has  been  ignored  in  the  literature.  To  be 
secure  when  operating  diskless,  two  factors  have  to  be  considered.  Page 
traffic  has  lo  be  encrypted,  and  workstations  have  to  be  confidcnl  of  the 
identity  of  their  disk  servers  so  thal  Trojan  horses  are  avoided. 

How  fast  will  encryption  have  to  be  done  lo  avoid  significant 
performance  penalty  when  running  diskless?  Cheriton  et  ai  IS]  present 
data  from  the  V  kernel  on  a  Sun  workstation  indicating  that  it  takes  about 
5  milliseconds  plus  disk  access  lime  to  remotely  read  or  write  a  random 
512-byte  block  of  data.  These  numbers  arc  for  file  access,  but  to  a  first 
approximation  wc  assume  that  they  also  hold  for  page  access.  Assuming 
that  the  server  does  writc-bchind.  a  page  fault  with  replacement  would 
involve  a  remote  page  write,  a  disk  access  al  the  server,  and  a  remote 
page  read.  This  yields  a  page  fault  service  time  of  30  milliseconds, 
assuming  a  typical  disk  latency  of  20  milliseconds.  IT  encryption  is  to 
degrade  paging  performance  by  no  more  than  5%.  il  has  to  be  possible  to 
encrypt  2  512-byte  pages  in  no  more  than  1 .5  milliseconds.  This  implies 
an  average  encryption  rale  of  about  700  kbytes  per  second.  For  the  more 
typical  Unix  page  size  of  4K  bytes,  an  encryption  rate  in  the  range  of  0.5 
to  !  Mbyte  per  second  slill  seems  necessary.  As  described  in  Section  9, 
encryption  hardware  wltosc  performance  meets  these  demands  seems 
feasible,  though  not  readily  available. 

Mutual  authentication  is  a  more  difficult  problem.  To  perform  a  3-phase 
authentication  handshake,  the  client  and  server  need  to  share  a  secret 
key.  Where  can  this  key  be  stored  at  the  client?  Embedding  it  in  the 
ROM  containing  the  boot  seqmncc  seem-  the  only  realistic  solution. 
However,  this  docs  violnlc  the  goal,  mentioned  in  Section  5.2.  of  nol 
storing  long-term  authentication  information  in  ihe  clear  on  workstations. 
Authentication  bused  on  public  keys  might  avoid  this  problem,  but  tliis 
lias  to  be  investigated. 

Aliliough  these  problems  are  nol  insurmountable,  we  know  of  no 
implementations  of  diskless  workstalions  that  address  them.  Concerns 
regarding  security  played  a  small  but  nontrivial  part  in  our  decision  to 
avoid  diskless  operation  in  Andrew. 

10.3.  Decentralised  Administration 

Our  discussion  lias  assumed  that  there  is  a  single  protection  domain  for 
all  of  Andrew,  and  that  the  Vice  id  and  Virtue  id  of  a  user  are  identical. 
While  this  is  true  at  present,  tile  growth  of  Andrew  makes  it  increasingly 
attractive  to  allow  multiple  proleclion  domains.  The  motivation  for  tliis 
comes  from  two  distinct  scenarios. 

First,  an  established  non-Andrew  timesharing  system  or  collection  of 
workstations  may  join  the  Andrew  environment.  An  existing  user  of 
both  environments  may  have  different  user  names  and  ids  in  the  two 
environments.  In  the  merged  environment,  Vice  and  Virtue  will  view  the 
individual  as  two  distinct  users.  Changing  the  id  in  eithei  environment  is 
difficult,  because  ids  are  embedded  in  long-teim  data  structures  in  both 
Unix  and  Vice  file  systems. 

Second,  individual  organisations  may  wish  to  administer  a  collection  of 
Vice  file  servers,  control  their  resources,  and  restrict  access  to  a  set  of 
Andrew  workstations.  Sucli  decentralised  operation  is  likely  to  provide 
grealer  flexibility  and  responsivene.s  lo  users.  It  would  also  allow  each 
organization  lo  have  its  own  set  of  privileged  groups,  such  us 
System;  Administrators. 
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A  mechanism  thal  addresses  these  issues  hy  supporting  independent 
Andrew  CetJs  |3 1 1  is  Iteing  iniplcincntcd.  A  tell  corresponds  to  a 
complete  autonomous  Andrew  system,  with  its  own  protection  domain, 
authentication  and  file  servers,  and  system  administrators.  The  name 
spaces  of  two  or  more  such  cells  can  be  merged  In  form  a  unified 
Andrew  environment.  Users  see  a  uniform,  seamless,  file  name  space 
mid  are  not  hindered  by  the  multiplicity  of  protection  domains. 

it  is  Venus  thal  makes  cells  transparent  duting  file  access.  Each  user  and 
group  id  in  llte  composite  environment  has  a  cell  id  as  its  prefix.  The 
Loci  program,  mentioned  in  Section  5.2.  allows  a  user  to  direct  his 
authentication  request  to  a  specific  cell.  The  authentication  procedure  is 
identical  to  that  described  in  Section  5.2.  except  that  tokens  are  stamped 
with  the  cell  id  of  the  authentication  server  wlto  created  them.  Venus 
maintains  a  collection  of  tokens,  one  secret-cleat  pair  for  each  cell  to 
which  llte  user  has  authenticated  himself  When  establishing  a  secure 
connection  to  a  Vice  server,  it  uses  die  tokens  apptopriate  to  the  cell  in 
which  the  server  is  located.  If  the  user  lias  not  authenticated  himself  lo 
dial  cell,  he  gels  Syslcm.AJiyUscr  privileges  in  it. 

llte  name,  id  and  password  of  an  individual  may  he  different  in  each 
cell.  Application  programs  that  translate  ids  lo  user  names,  such  as  LS. 
have  to  he  modified  lo  lake  this  into  account.  However,  long-term  data 
structures  on  disk  do  not  have  lo  be  modified  lo  allow  access  to  multiple 
cells.  Since  all  Vice  files  stored  on  a  server  belong  to  the  same  cell,  their 
access  lists  speedy  only  users  and  groups  who  are  in  that  cell.  Thus  a 
server  does  not  need  the  cell  prefix  when  performing  an  access  list 
check.  The  prefix  is  used  only  when  a  secure  KP(.'  connection  is  being 
established. 


1 1.  Risk  Analysis 

In  litis  section  we  briefly  consider  how  security  could  be  subverted  in 
Andrew.  Our  analysis  is  nol  intended  lo  lie  exhaustive  not  is  it  a  ptoof  of 
security.  Its  primary  purpose  is  to  sunnmtiisc  the  discussions  ol  llte 
preceding  sections  of  this  paper.  A  secondary  goal  is  to  illustrate  llte 
complexity  of  applying  relatively  simple  security  algorithms  to  a  real 
distributed  environment  of  substantial  scale  and  diversity. 

A  fundamental  assumption  in  Andrew  is  that  encryption  of  sufficient 
strength  and  speed  is  available  lo  Vice  and  Virtue.  Otherwise  it  is  trivial 
lo  violate  security.  Pot  the  putposcs  of  this  section,  we  assume  that  all 
servers  and  workstations  have  DES  hardware.  We  also  assume  that  all 
RPC  connections  on  behalf  of  users  arc  authenticated  and  fully 
encrypted. 

Low-Icvci  network  attacks  can.  at  worst,  result  in  denial  of  service  to 
users.  Since  KPC  packets  are  encrypted  end-to-end.  eavesdropping  will 
:iol  reveal  useiul  information.  Mutilating  RPC  packets  will  not  violate 
security  either.  Such  packets  will  he  rejected  by  the  recipient  because 
RPC  sequence  numbering  information  is  encrypted  and  it  is  extremely 
unlikcty  thal  a  mutilated  RPC  packet  will  have  the  correct  sequence 
number  when  decrypted. 

With  patience  and  considerable  computational  resources,  a  malicious 
individual  could  eavesdrop  on  client-server  traffic  and  break  the  key 
under  which  the  traffic  is  encrypted.  Since  a  new  random  session  key  is 
generated  when  an  RPC  connection  is  established,  breaking  that  key  will 
only  give  access  lo  one  server.  To  masquerade  as  the  user,  tlte 
eavesdropper  would  have  lo  carefully  intersperse  fake  RPC  requests 
encrypted  under  the  session  key.  Tile  session  key  is  not  adequate  to 
establish  connections  with  other  servers. 

Greater  damage  can  be  done  by  breaking  the  key  in  secret  and  clear 
tokens.  One  way  lo  do  this  is  to  break  (lie  key  used  by  the  authentication 
server  for  encrypting  secret  tokens.  Periodic  changing  of  this  key  is 
therefore  essential.  An  alternate  way  to  break  the  key  in  a  token  pair  is 
lo  observe  it  number  of  BIND  requests  dial  involve  the  same  pair  of 
tokens.  This  is  unlikely,  because  tokens  expire  after  24  Ilnurs,  and  the 
number  of  HIND  requests  made  by  a  user  in  that  period  is  nol  likely  lo  be 
sufficient  to  mount  a  serious  key -breaking  effort.  A  compromised  token 
pair  allows  the  miscreant  lo  establish  secure  RPC  connections  with  the 
privileges  of  the  victim  on  any  Vice  file  server.  It  is  not  adequate, 
however,  to  establish  u  secure  connection  to  die  authentication  server. 


Tlte  most  damage  is  caused  when  the  password  of  a  user  is  broken, 
particularly  if  he  is  a  system  administrator.  However,  the  password  is 
typically  used  only  once  a  day  when  the  user  is  contacting  an 
authentication  server  for  tokens.  The  standard  practice  of  changing 
passwords  periodically  will  reduce  the  total  amount  of  information 
available  for  key-breaking. 

A  well-known  mode  of  attack  is  via  a  Trojan  horse.  Public  workstations 
arc  particularly  susceptible  lo  litis.  A  Trojan  LoctN  piogram  on  a 
workstation  could  compromise  the  password  of  every  individual  wlto 
uses  that  workstation.  As  mentioned  in  Section  3.  a  concerned  site 
should  ensure  that  rebooting  a  workstation  standalone  is  •tttpossiblc  for 
normal  users.  This  would  defeat  the  simplest  way  lo  install  a  Trojan 
horse. 

A  more  subtle  way  to  introduce  a  Trojan  hot  sc  is  by  masquerading  as  a 
server  that  is  temporarily  down,  and  handing  out  fraudulent  binaries. 
During  their  reboot  sequence,  workstations  fetch  new  copies  of  a  lew 
local  binaries  from  Vice  over  insecure  connections.  To  avoid  this 
problem,  automatic  updating  on  reboot  should  be  disabled.  Instead,  the 
owner  of  Pie  workstation  should  explicitly  update  these  files,  using 
binaries  fetched  on  his  secure  RPC  connection. 

Workstations  with  multiple  logged-in  users  make  a  number  of  other 
security  threats  possible.  A  malicious  user  with  superuser  privileges 
could  cause  Venus  to  dump  core,  examine  tlte  dump  and  extract  the 
tokens  of  other  logged-in  users.  Andrew  does  not  provide  any  special 
mechanisms  to  protect  against  such  threats.  As  mentioned  in  Section  3. 
users  of  a  sinned  workstation  have  lo  trust  till  individuals  who  could 
become  superuser  on  that  workstation.  A  superuser  call  also  read  and 
modify  all  cache  copies  of  files  on  the  workstation. 

Vice  is  critically  dependent  on  the  physical  security  of  its  servers  and  on 
carefully  restricted  superuser  access  on  them.  Pot  maximum  security, 
servers  should  disallow  THLNt-T  access.  Physically  seethe  machine 
looms  and  trustworthy  operators  arc.  of  course,  also  essential.  A 
malicious  individual  with  superuser  access  on  a  server  could  reud  or 
modify  all  Vice  file  data. 

Membership  in  the  group  SysIcimAdiuinisliators  lias  lo  be  carefully 
guarded.  A  system  administrator  can  modify  any  access  list  ill  llte 
system,  and  cun  therefore  read  or  write  any  file.  He  can  also  change 
storage  quotas  and  modify  the  ownership  of  files.  For  increased  security, 
it  would  be  relatively  simple  lo  modify  Vice  l<)  gram 
SysIcnitAtlministraloi  privileges  only  to  individuals  who  arc  logged  in  at 
one  of  a  specific  set  of  physically  secure  workstations,  in  addition  lo 
being  authenticated. 

To  keep  things  in  perspective,  it  should  be  noted  that  this  section  is 
deliberately  negative  in  tone.  Most  of  the  scenarios  described  here  are 
highly  unlikely,  and  typically  involve  the  violation  of  the  assumptions 
discussed  in  Section  3  A  site  which  adheres  to  those  assumptions  will 
find  Andrew  more  secure  than  any  existing  distributed  system  of 
comparable  functionality.  Further,  in  spile  of  die  attention  it  pays  to 
security,  Andrew  remains  it  highly  usable  system. 

12.  Conclusion 

As  mentioned  at  the  beginning  of  this  paper,  Andrew  is  an  evolving 
system.  A  number  of  changes  have  been  made  since  tlte  date  of  the 
snapshot  on  which  this  paper  is  based.  Many  of  these  changes  have  been 
improvements  to  existing  functionality.  The  protection  database  now 
stores  its  index  as  part  of  itself  rather  than  in  a  separate  file.  This 
eliminates  llte  occasional  inconsistences  between  index  and  data  that 
used  to  occur  when  propagating  protection  domain  information.  Tlte 
remote  procedure  call  mechanism  described  in  Section  5.1  has  been 
replaced  by  one  that  is  more  stringent  in  its  use  of  memory.  The  primary 
reason  for  this  change  was  the  desire  to  run  Venus  on  workstations  with 
severly  limited  physical  memory.  The  details  of  the  authentication 
handshake  arc  different  from  (hat  described  in  Section  5.1.  but  the  same 
effect  is  achieved.  We  are  ill  die  process  of  designing  a  faster  encryption 
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device  tor  the  IBM  KT-IVs.  as  discussed  in  Section  linalh.  ihe  cell 
mechanism  referred  in  m  Section  in  ^  in  ,i  Nigniluant  dumge  that  will 
jmovuJo  new  (uncUonalitv  when  con iplcie 

Wv  have  long  appreciated  (lie  need  lot  use  in  to  l*.c  able  lo  ciealc  and 
manipulate  gtoups  themselves.  uthci  than  subunit.. .g  requests  w  the 
administrators  id  Andrew.  A  r^oinruw  Snvn  «hu  implements  Hus 
tuikhouality  has  been  planned  hut  not  implemented  yet.  This  set  vet 
cuUd  he  an  extension  ol  the  existing  authentication  serve t  and  would 
allow  uv  to  merge  cecums  iidniiuutinii  that  is  current1)’  distributed  ovci  a 
number  ol  difleient  data  structures’  the  “/cMc/passwd-  ’  file  on 
workstations.  the  passwoid  database  041  authentication  set  vers,  the 
piotevlum  domain  database  on  hie  seivcis.  and  the  tiles  containing  dneci 
gtoup  mcuiU'iship  minimal  ion  limn  which  system  personnel  generate 
the  otofeclMHi  domain  database  This  change  would  consideiahly 
simplify  admmiMiatioii  and  operation  oi  Andicss. 

In  eomltiMon.  we  believe  that  seem  us  issues  will  assume  greater 
sigmlicaiue  as  diMitbuted  systems  ol  increasing  si/e  and  complexity  aie 
built.  A  substantial  amount  01  tbeoietic.il  rescind)  lias  already  been  done 
on  seem  1  u  algorithms  (or  d)Mt  United  envuoiinienls.  Applying  those 
pt ilk  iples  lo  the  design  o\  real  systems  is  complicated  b\  the  many  locls 
ol  absh. niton  spanned.  b\  the  need  lor  compatibility  and  by  the  manv 
detailed  aspects  ol  the  systems  Uul  me  U  tec  leu.  And'ew  p;  an  alletnpi  to 
seiuntsK  addie sn  these  issues  It  ollcis  subst.uuiallv  greater  secuuty 
than  cMsiing  distributed  s\ stems  without  sigmlkant  loss  .»|  usability  01 
jki  ionium  c 


<  l  ed ils 

the  sin ui ns  mechanisms  dcurilk-d  lieu*  wete  dcvclojx*d  by  the  Andrew 
Pile  Sssiein  group.  whose  membership  ocpi  time  has  included  lohu 
Howard.  Mu  had  Ka/al.  I).»vul  King,  Mteiii  Menees.  l>aud  Nichols. 
M  Salvanarasiiiian.  Kohen  Nidvbotham.  Mu  had  West,  and  bibvaid 
/avas  Pichminaiv  design  w*nk  on  sec  ill  its  in  Andiew  was  done  by 
l>.i\id  1  iillonl.  '•I  .Natyanaiayartan  and  Allied  Spec  toi 

Mans  ol  the  mediaitums  described  111  this  paper  wm-  unpl.  nieimnl  bs 
M  Salsau.dasatian  Ihisul  Nn  lints  and  Mu  had  f.a/.u  uuunbuted  to  the 
incchainsms  in  Smite.  while  Micli.id  West mimihiiicd  to  those  m  \  k.‘ 

1  he  sec  unis  mechanisms  that  suppoit  Ih  Senci  wen  built  bs  Ians 
K.ipci  and  Jonathan  Koscnbci c  Paul  »  untiles  designed  uul 
impkiiii’tiied  the  ciu.r\ptio.i  haidssate  hu  k  I  Pi  s 

James  Kistlet.  James  Mono,  loiuihati  kosciibcig.  kobeit  Saieom  P.lleii 
Siegel  and  l  long  Tvgai  provided  saluable  coiniuenls  on  tho  paper 
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This  figuie  shows  Ihc  sequence  t>r  events  in  the  iiini*  liuinislmkc.  Gucl*  aitow  icpicscnls  n  pnekri.  The  notation 
inviuiH  thiil »;  is  encrypted  with  key  h.  11  ic  Uisl  jwkei  of  (he  exchange  conveys  n  mmtomly  selected  .session 
key  tuul  u  miidomly  selected  initial  t<c<|iicncv  mi  in  bet  in  the  cliirni. 

Figure  3:  RPC’  HIND  Authentication  Handshake 
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Each  cutty  amcvpojuls  to  iiifoitmitimi  :ih«»m  ••nc  11*01  11k*  lirM  Held  |c  the  Vice  id  «»['  ;he  usei.  the  second  liis 
cnuypled  passwntil:  the  third  field  is  the  name  o|  Ihc  ir*ri.  Otliei  fields  me  igiinied  by  the  mi  1  ho  nti  cation  scivci. 
Tlie  fii-st  few  lines  conespond  In  entiles  that  ivciv  piosenl  when  ihc  database  wus  initialised-  The  entries  al  Ihc 
bottom  ivptvNcnl  mollifications.  Bucli  iiHidifieiiiion  is  nipped  with  the  identity  of  the  usci  making  the  change  mid 
ihc  tiniu  the  change  wus  made. 

Figure  4:  Excerpt  from  Authentication  Database 
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Date:  Mon  Sep  29  00:51:13  1906 

09:51:13  Server  suoaaaafully  aterted 

11:03:49  Authentication  failed  for  "CaOt"  from  128.2.14.11 

11:05:22  Authentication  failed  for  "feOt”  from  128.2.14.11 

11:05:54  Authentication  failed  for  "an09"  from  128.2.14.8 

11:09:50  Authentication  failed  for  "whOa"  from  128.2.14.4 

11:10:25  Authentication  failed  for  "whOa"  from  128.2.14.4 

11:12:20  Authentication  failed  for  "ao07"  from  128.2.14.14 

11:12:50  Authentication  failed  for  "whOa”  from  128.2.14.4 

11:20:43  Authentication  failed  for  "aoQ7"  from  128.2.14.14 

12:00:24  Authentication  failed  for  "ka2n"  from  128.2.13.3 

13:58:46  Authentication  failed  for  "dana"  from  128.2.243.3 

15:22:26  Authentication  failed  for  "dtla"  from  128.2.17,17 

16:16:17  AuthchangePaaad ( )  attempt  on  dh2u  by  ja0c  denied 

16:19:17  AuthChengePasadO  attempt  on  dh2u  by  je8c  denied 

16:24:57  Authentication  felled  for  "akll"  from  128.2.14.14 

16:36:53  Authentication  failed  for  "jaSa"  from  128.2.17.4 

20:46:03  Authentication  failed  for  "jc55"  from  128,2.14.11 

21:47:13  Authentication  failed  for  "oa2m"  from  128.2.14.20 

22:20:17  Authentication  felled  for  "}r45"  from  128.2.17.20 

23:30:16  Authentication  failed  for  "1116"  from  128.2.14.20 

23:30:56  Authentication  failed  for  "1116"  from  128.2.14.20 

23:44:58  Authentication  failed  for  "efOu"  from  128.2.11.62 

23:53:59  Authentication  failed  for  "gwOv"  from  128.2.36.6 

Pate:  Tue  Sep  30  09:51:50  1996 

09:51:50  Authentication  failed  for  "bkOu"  from  129. 2. 14. 12 

09:56:23  Authentication  failed  for  "bkOu"  from  128.2.14.12 

09:57:51  Authentication  failed  for  "bkOu"  from  128.2.14.12 

10:16:48  Authentication  failad  for  "jeOx"  from  12B.2.14.3 

11:22:16  Authentication  failad  for  "ia24"  from  129.2.14.10 

11:32:02  Authentication  failed  for  "mb3h"  from  129,2.14.16 

11:35:55  Authentication  failed  for  "le24"  from  12B.2.14.10 

12:39:45  Authentication  failad  for  "km35"  from  129.2.14.9 


Till--  Hguie  shows  ivpit  nl  entries  from  ihe  tuiihcniicniinn  log.  Mo*.  I  of  the  cniiic.-t  iu>?  invalid  mithciilicnlinn 
nllcmpK  piohahly  vikim'iI  I'y  n  usi'i  typing  in  his  password  huoHcoily.  liueh  oniiy  identifies  llie  user  nmi  the 
workstation  fmm  which  the  oprinlitin  wm  all  cm  pled.  Twit  of  the  cullies  mu  fulled  nl  tempi*  by  olio  Usui  In 
change  lltc  pnsswojd  ol  onolhei  u.se  i. 

Figure  5:  Excerpt  from  Authentication  Log 


mosart>  Is  la  /cmu^itc/suiya/sU 
Hocmal  rights: 

System : ZTC . PlleflyatemGrcup  rlidwk 
Syatem : AnyUeer  rl 
■atya  rlidwka 
Hagative  rights: 

System : ITC .User Inter f aceCtoup  rlidwka 
moaart> 

This  figutc  slums  how  iu>  access  list  Is  displayed  in  Ami  tv  w.  The  string  "im»/nrt>”  is  ihe  pmntpt  by  lltc 
workstation.  The  command  "Is  |n“  lists  the  specified  dlrvcloiy.  Note  the  use  ol  negative  rights:  a  member  of 
System  rlTCUwilntcrfuceOmup  would  liuve  no  lights  mi  this  d  licet  my.  even  though  System  :AnyUser  has  lend 
utul  lookup  tights. 

Figure  6:  Access  List  on  n  Vice  Directory 
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7:  tiXi'crPl  fr»“l  v>i-c  Pmicciitm  Domain  Dambusc 
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moiart>  la  -1  /arau/itc/aatya 
total  120 
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Tills  Is  iut  example  of  n  directory  listing  hi  Andrew.  For  files,  the  status  of  the  uwncr  mode  bit*  ore  shown  us 
"r".  "w"  niuJ  "x".  These  bits  tire  not  shown  for  directories,  since  inode  bits  du  not  apply.  Note  the  use  of  a 
symbolic  link  to  obtain  u  protection  status  for  (he  file  named  “persona]"  that  is  different  front  other  flies  In  this 
directory.  The  file  is  physically  located  hi  the  directory  “private"  which  has  more  restrictive  access  than  the 
directory  shown  here. 

Figure  8:  Listing  of  a  Vice  Directory 
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ABSTRACT 

This  paper  explores  various  research  issues  that  need  to  be 
addressed  in  process  models  and  automated  support  environ¬ 
ments  to  bettei  build  trusted  systems  for  Defense  needs.  A 
broader  notion  of  trustworthiness  of  systems  is  discussed;  the 
shortcomings  of  the  typical  security  engineering  life  cycle  and 
the  nature  of  the  software  development  life  cycle  ns  well  as 
the  related  trust  issues  are  explored.  The  paper  then  describes 
several  contributing  technologies  that,  when  merged,  offer  a 
next  generation  integrated  approach  to  trusted  system  devel¬ 
opment  to  better  support  Defense  needs.  The  paper  concludes 
with  a  set  of  recommendations  for  research  directions  to  he 
pursued. 

BACKGROUND 

A  significant  long-range  problem  that  needs  to  be  ad¬ 
dressed  is  the  critical  need  for  systems  to  meet  major  current 
and  future  Defense  system  requirements  for  security,  integrity 
and  high  reliability.  The  current  generation  software  develop¬ 
ment  paradigms  for  producing  systems  is  woefully  inadequate 
for  developing  and  demonstrating  mission  critical  systems  in 
which  we  have  a  high  degree  of  trust  in  their  correct  and  se¬ 
cure  operation.  The  existing  formal  security  modeling  and 
specification  and  verification  technologies  that  have  been  de¬ 
veloped  and  applied  primarily  in  the  trusted  systems  arena  are 
labor-intensive  and  inadequately  supported  with  cost-effective 
analysis  techniques  and  tools.  Various  computer  security  pro¬ 
jects  in  which  formal  methods  have  been  applied  in  the  past 
have  produced  systems  with  inadequate  performance  to  meet 
Defense  system  needs  and  with  system  implementations  that 
bear  little  resemblance  to  the  abstract  proofs  of  security  or 
"trustworthiness”  about  them.  To  date,  these  formal  methods 
have  not  been  coupled  and  effectively  integrated  with  other 
testing,  analysis  and  configuration  management  techniques 
into  a  sound  engineering  development  paradigm  for  large 
complex  systems  meeting  future  DoD  requirements.  The 
trusted  systems  that  have  been  produced  to  meet  the  higher 
levels  of  the  Trusted  Computer  System  Evulua.ion  Criteria 
i'TCSEC)  are  not  widely  applicable  and,  due  to  their  limita¬ 
tions,  ire  not  replacing  less  secure  and  less  trusted  systems 
that  are  in  widespread  use  in  tnc  Defense  community. 

This  paper  explores  some  of  the  issues  to  be  addressed  in 
development  paradigms  anc!  automated  support  environments 
to  meet  the  challenge  of  current  and  future  Defense  system 
trust  requirements. 

THE  PROBLEM 

Although  good  progress  has  been  made  in  the  lust  several 
years  in  producing  secure  components,  extending  this  pro¬ 
gress  to  building  secure  multi-component  operational  systems 
has  been  slow,  expensive  and  complex.  Some  major  aspects 
of  the  problem  include: 

*  Expansion  or  variation  of  the  definition  of  security  beyond 

confidentiality  as  it  applies  to  large  systems  that  are  mis¬ 
sion  critical. 
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•  The  nature  of  the  security  engineering  life  cycle,  which 
often  is  separate  from  and  parallel  to  the  system  develop¬ 
ment  life  cycle. 

•  The  nature  of  the  software  development  life  cycle,  which 
no  longer  fits  a  "waterfall"  paradigm  and  for  which  new 
process  models  and  supporting  development  environments 
must  be  explored. 

•  The  tendency  of  contributing  technologies  like  formal  veri¬ 
fication  and  Ada  tool  development  to  be  isolated  and  not 
integrated  with  mainstream  system  development  environ¬ 
ments. 

These  aspects  will  be  discussed  in  the  following  sections. 

VARIATIONS  ON  THE  DEFINITION  OF  SECURITY 

Traditionally,  discussions  on  security  have  concentrated  on 
a  definition  of  security  to  mean  confidentiality,  that  is,  the 
protection  against  unauthorized  disclosure  or  modification  of 
data.  Confidentiality  was  considered  more  important  than 
other  aspects  of  the  system  requiring  more  expertise  and  at¬ 
tention.  The  activity  of  separating  the  system  into  Trusted 
Computing  Base  (TCB)  and  non-TCB,  or  trusted  and  un- 
trusted  components,  was  formulated  so  that  more  attention 
(verification,  testing,  design  scrutiny)  could  be  placed  on  the 
trusted  part  In  this  regard,  such  things  as  denial  of  service 
were  not  strictly  security  concerns. 

Although  denial  of  service  is  not  strictly  security  related 
per  the  TCSEC,  for  programs  which  have  a  high  decree  of 
mission  criticality,  the  line  between  security,  denial  of  service 
and  mission  criticality  becomes  blurred.  In  fact.  SDI  is  one  of 
these  mission  critical  programs.  In  the  SDI  security  approach, 
confidentiality  is  only  one  leg  of  three  aspects  simultaneously 
addressed:  confidentiality,  assured  service  and  integrity.  In 
this  case,  confidentiality  is  concerned  with  identification  and 
authentication,  least  privilege,  object  reuse,  audit,  data  protec¬ 
tion,  key  management,  TEMHiST,  personnel  security,  OB- 
SEC,  traffic  flow  security,  trusted  facility  management  and 
trusted  distribution.  Integrity  is  concerned  with  error  detection 
and  correction,  data  authentication,  source/recipient  authenti¬ 
cation,  consistency,  concurrency  controls,  and  N-man  control. 
Assured  service  is  concerned  with  both  assured  communica¬ 
tion  service  and  assured  computing  service.  Assured  commu¬ 
nication  service  includes  the  link  level,  the  network  level,  and 
the  application  level.  Assured  computing  service  includes 
hardware  and  software  assurance,  trusted  recovery,  deadlock 
and  algorithm  design,  as  well  as  component  fault  tolerance 
and  secure  failure.  This  is  an  excellent  example  of  where  a 
process  model  and  development  environment  are  needed  in 
which  several  aspects  are  equally  important  in  the  competition 
for  design  scrutiny  and  dollars. 

THE  SECURITY  ENGINEERING  LIFE  CYCLE 

Figure  1  shows  the  Security  Engineering  Life  Cycle  as  a 
parallel  activity  to  the  system  development  process.  Through- 


out  the  life  cycle  of  the  project,  depending  on  the  project  size, 
a  security  engineer  or  a  group  of  security  engineers  performs 
the  analysis  and  oduces  documentation  to  support  the  secu¬ 
rity  engineer!'  .Tv  system,  This  begins  with  the  Security 
Requirement.  "  •  's  phase,  which  leads  to  the  formulation 
of  security  |  .  .  the  security  model. 

Next  is  the  .i.st  of  series  of  risk  and  vulnerability  assess¬ 
ments  to  be  performed.  The  second  one  should  be  performed 
between  preliminary  design  and  critical  design,  as  important 
design  tradeoffs  are  being  made.  At  this  point,  covert  channel 
analysis  can  also  be  performed,  so  that  any  identified  covert 
channels  can  be  addressed  in  the  critical  design.  Another  risk 
assessment/vulnerability  analysis/covert  channel  analysis 
should  be  done  when  the  system  is  being  realized  in  code,  to 
ensure  that  no  new  vulnerabilities  or  covert  channels  have 
been  introduced. 

After  the  security  model  is  done,  the  Security  Architecture 
is  produced,  which  includes  all  aspects  relevant  to  the  security 
posture  at  that  point  in  the  design.  It  should  include  assump¬ 
tions  about  the  system  operation,  assertions  about  the  security 
enforcement  techniques,  an  initial  partitioning  of  the  system 
into  trusted  and  untrusted  segments,  expected  operational  sce¬ 
narios,  and  an  initial  security  design  of  the  Trusted  Comput¬ 
ing  Base.  Next  comes  the  Descriptive  Top  Level  Specification 
and  the  Formal  Top  Level  Specification  as  specified  by  the 
TCSEC.  Finally  comes  Security  Testing  Activities  and  Docu¬ 
mentation,  and  then  Certification  and  Accreditation  activities. 

There  are  several  important  aspects  that  are  inadequate  in 
this  life  cycle  to  meet  current  and  future  Defense  needs: 

•  It  is  too  expensive.  It  costs  to  maintain  a  staff  of  security 
engineers  and  to  produce  extensive  documentation  which 
must  be  carefully  configuration  managed,  and  maintained. 

•  The  parallel  nature  of  the  process  focuses  exclusively  on 
security  rather  than  on  trust  and  assurance  of  the  system 
as  a  whole.  This  lack  of  integration  of  security  into  the 
mainstream  life  cycle  undermines  broader  trust  and  integ¬ 
rity  concerns  of  a  system  with  a  dedicated  mission. 

•  The  separation  of  security  engineers  from  normal  design 
and  development  engineering  often  sets  project  groups 
against  one  another  as  important  design  decisions  are 
made  and  tough  tradeoffs  must  be  made  on  requirements 
allocation,  performance,  etc. 


o  It  is  labor  intensive  because  there  is  little  automation 
which  supports  this  parallel  life  cycle.  Tool  use  is  spo¬ 
radic,  at  the  discretion  of  individual  subsystem  managers, 
and  is  not  well  integrated  with  other  project  software  de¬ 
velopment  tools. 

•  It  is  fragile.  The  life  cycle  does  not  take  advantage  of  the 
true  nature  of  building  systems  today,  which  involves  feed¬ 
back,  iteration  and  interaction  as  shown  in  Figure  2.  The 
interactive  nature  involves  prototypes,  analyzing  the  ef¬ 
fects  of  one  requirement  or  design  alternative  on  the  rest 
of  the  system,  modeling  and  sensitivity  analysis.  The  par¬ 
allel  life  cycle  is  much  more  rigid.  If  any  assumptions  are 
changed  along  the  way,  the  model  and  design  can  be  in¬ 
validated  and  a  “startover"  can  result. 

TRUST  ISSU'^  IN  SOFTWARE  DEVELOPMENT  LIFE 
CYCLE 

As  a  consequence  of  the  problems  discussed  above,  the 
current  typical  software  development  life  cycle  is  inadequate 
in  meeting  the  needs  of  developing  complex  systems  having  a 
high  degree  of  trust  and  reliability  requirements.  Current  and 
future  system  requirements  raise  trust-related  issues  for  both 
the  process  model  and  the  software  development  environment 
that  are  not  being  addressed  today.  These  include  the  need 
for: 

•  Effective  development  paradigm  for  trusted  systems. 

•  Access  control,  trustworthiness  and  integrity  of  the  soft¬ 
ware  development  environment. 

•  Support  for  the  trusted  system  evaluation  process. 

Most  software  systems  today  are  developed  with  a  "water¬ 
fall"  method  of  software  development  which  was  appropriate 
when  it  was  introduced  but  no  longer  meets  the  needs  of  de¬ 
veloping  complex  systems.  The  waterfall  paradigm  treats  the 
software  development  cycle  as  a  series  of  sequential  steps, 
each  of  which  is  completed  before  the  next  step  is  begun. 
First  the  requirements  are  completely  specified,  then  the  pre¬ 
liminary  design  is  completely  done,  and  so  on.  The  waterfall 
model  does  not  adequately  address  concerns  of  developing 
program  families  and  reusable  components,  nor  does  it  ade¬ 
quately  organize  software  to  accommodate  change.  It  assumes 
a  relatively  uniform  progression  of  elaboration  steps  and  does 
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no 


not  accommodate  the  realistic  evolutionary  development 
needed  to  develop  complex  systems  and  which  is  made  possi¬ 
ble  by  current  rapid  prototyping  capabilities.  The  waterfall 
model  also  does  not  address  the  possible  future  modes  of 
software  development  such  as  those  incorporating  program 
transformation  capabilities  or  knowledge-based  software  capa¬ 
bilities. 

The  current  development  paradigm  used  for  trusted  sys¬ 
tems  is  security  engineering  as  a  parallel  activity  to  the  water¬ 
fall  development  process  as  illustrated  in  Figure  1  and 
described  in  the  previous  section.  This  is  an  inadequate  and 
ineffective  approach  for  building  complex  systems  having  re¬ 
quirements  for  a  high  degree  of  reliability,  integrity  and  trust¬ 
worthiness.  Wha;  is  needed  is  a  next  generation  development 
paradigm  for  trusted  systems  that  effectively  couples  and  inte¬ 
grates  a  new  process  model  with  formal  methods  and  security 
engineering  methodologies  and  puts  these  critical  develop¬ 
ment  components  in  the  context  of  sound  software  engineer¬ 
ing  practices  and  automated  support  environment  necessary 
for  developing  large  complex  Defense  systems.  This  new 
process  model  should  be  a  risk-driven  process  model;  that  is, 
it  should  be  a  process  model  which  can  take  into  account  the 
particular  vulnerabilities  and  risks  and  environment  of  the  tar¬ 
get  system  at  each  stage  of  development.  This  enables  the 
development  process  to  react  to  feedback  and  changes  with 
appropriate  elaboration  steps  to  reduce  the  identified  risks, 
for  example,  additional  system  prototyping  or  formal  specifi¬ 
cation, 

A  second  trust-related  issue  to  be  addressed  is  the  impact 
on  the  software  engineering  environment  to  be  used  in  support 


of  the  trusted  target  system  development,  Current  software 
engineering  environments  do  not  adequately  address  these 
needs.  The  Trusted  Computer  System  Evaluation  Criteria 
were  developed  for  operating  systems  and  do  not  adequately 
address  the  trustworthiness  needs  of  the  software  engineering 
environment.  Issues  identified  are  the  appropriate  level  of  the 
Evaluation  Criteria  as  a  goal  for  software  engineering  environ¬ 
ments  to  be  used  for  trusted  systen.  development,  architec¬ 
tural  impacts  on  the  environment  and  need  for  tool  and 
project  database  integrity  in  the  environment.  These  issues  are 
only  now  starting  to  be  considered  in  efforts  to  standardize  the 
interface  specifications  for  software  engineering  environments 
for  security  applications.  More  detailed  analysis  of  these  is¬ 
sues  is  needed  before  standardization  efforts  get  cast  in  con¬ 
crete. 

Currently,  there  is  no  effective  integration  of  Uv  tools  to 
support  formal  methods  in  trusted  system  development  with 
other  development  and  analysis  tools  needed  to  support  the 
software  engineering  process.  There  is  no  support  in  environ¬ 
ments  for  the  appropriate  notations,  descriptions  and  repre¬ 
sentations  nccdcti  for  trusted  system  development.  In  place  of 
a  consistent  dcsign/development  notation  throughout  the  de¬ 
velopment,  tools  are  applied  to  different  notations  with  gaps 
between  the  notations  requiring  manual  translation.  For  exam¬ 
ple,  at  the  security  model  and  high  level  specification  stages, 
the  notation  of  a  formal  specification  language,  such  as  Gypsy 
or  Special  might  be  used.  Latter,  in  the  preliminary  design 
stage,  a  pseudo  code  language  such  as  PSL  might  be  em¬ 
ployed.  Since  the  two  notations  are  different,  automated 
traceability  between  the  two  is  very  difficult.  The  implementa¬ 
tion  is  often  carried  out  in  yet  another  notation,  for  example. 
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in  C,  Pascal  or  Ada.  Added  to  that  arc  the  variety  of  rotation 
which  are  employed  for  testing  and  configuration  manage¬ 
ment. 

Without  a  consistent  notation,  traceability  throughout  the 
development  is  very  difficult,  if  not  impossible,  for  a  complex 
system.  Formal  specification  and  verification  technology  is  not 
integrated  with  and  not  on  a  par  today  with  the  other  tools  and 
techniques  used  in  system  development,  is  not  in  widespread 
use  today  and  is  not  used  in  a  cost-effective  manner  for  criti¬ 
cal  system  components. 

Another  trust  issue  of  software  engineering  environments 
for  trusted  system  development  is  the  need  for  a  trustworthy 
and  controlled  environment  for  the  development  life  cycle. 
This  includes  concern  for  trustworthiness  of  the  tools  in  the 
environment  and  the  integrity  of  the  project  database,  access 
control  of  the  developers  to  portions  of  the  developing  target 
system,  configuration  management  and  control  of  the  environ¬ 
ment  as  well  as  access  control  to  the  project  database  and  the 
tools.  These  concerns  are  currently  not  being  addressed. 

Current  software  engineering  environments  also  do  not 
provide  support  for  the  trusted  system  evaluation  process,  i  e . . 
for  evaluation  of  the  target  mission-critical  trusted  system 
against  the  appropriate  Evaluation  Criteria.  Needed  support 
would  include  evaluation  tools  in  a  controlled  environment  for 
the  initial  evaluation  as  well  as  any  required  periodic  re- 
evaluation  of  a  system  to  retain  its  evaluation  level.  Such 
automated  tools  might  include  tools  for  documentation  trac¬ 
ing,  covert  channel  analysis,  and  configuration  management. 
Some  of  the  analysis  tools  useful  for  evaluation  are  part  of  a 
normal  suite  of  development  tools  within  an  environment 
while  others  are  for  evaluation  purposes  only.  There  must  be 
access  control  to  those  tools  as  well  as  a  high  degree  of  trust 
in  their  proper  use. 

The  various  trust-related  issues  in  development  paradigm, 
software  development  environment  and  support  for  the  evalu¬ 
ation  process  need  to  be  addressed  in  order  to  meet  the  needs 
ol  future  complex  systems  requiring  a  high  degree  of  trust¬ 
worthiness  of  operation  and  integrity  of  the  system. 


CONTRIBUTING  TECHNOLOGIES  EOR  TRUSTED 
SYSTEM  DEVELOPMENT 

The  broau  computer  security  and  software  engineering 
communities  have  a  challenge  and  an  opportunity  to  effec¬ 
tively  address  the  issues  raised  in  the  previous  sections  tor 
developing  trusted  systems  by  integrating  several  fundamental 
contributing  technologies  to  achieve  a  better  result  than  any  of 
the  components  alone  could  produce.  These  technologies  in¬ 
clude  a  new  risk-driven  process  model  coupled  with  formal 
methods  and  security  engineering  methodologies  and  inte¬ 
grated  automated  support  environments  incorporating  tools 
needed  for  developing  large  complex  Defense  systems.  In  or¬ 
der  to  have  widercaching  impact,  we  propose  that  this  technol¬ 
ogy  integration  be  done  in  the  context  of  Ada  trusted  system 
development  for  DoD. 

While  each  of  the  contributing  technologies  exist  in  some 
fas  hion  today,  most  are  state-of-the-art  rather  than  state-of- 
the-practice.  Nor  are  they  used  in  an  integrated  manner  in  a 
unifying  framework  for  trusted  system  development.  In  addi¬ 
tion,  the  communities  of  interest  (computer  security,  formal 
methods/verification,  software  engineering,  software  environ¬ 
ments)  have  not  communicated  very  much  or  very  effectively 
with  one  another.  Each  community  of  interest  is  narrowly  fo¬ 
cused  on  only  one  aspect  of  what  is  necessary  for  building 
next  generation  DoD  systems.  Positive  impact  on  future  DoD 


trusted  system  requirements  will  be  based  on  coupling  these 
efforts. 

The  computer  secunty  community  has  focused  on  security 
aspects  in  the  narro  ■'  sense  (as  defined  in  TCSEC)  rather 
than  on  more  broadly  defined  trust.  The  needs  of  computer 
security  have  driven  the  development  of  security  policy  mod¬ 
els,  security  engineering  methods  and  formal  specification 
and  verification  methods,  languages  and  tools.  This  driving 
force  has  helped  focus  the  efforts  to  solve  problems  in  com¬ 
puter  security  but  have  not  adequately  addressed  trust  issues 
such  as  those  to  be  found  in  SOI  or  other  mission  critical 
systems.  It  is  not  clear  whether  the  techniques  developed  will 
scale  up  effectively  or  whether  significant  enhancement  and 
redevelopment  will  be  necessary.  Current  SDI-sponsored  secu¬ 
rity  architecture  studies  are  beginning  to  address  some  of  the 
broader  trust  issues. 

The  formal  methods/verification  community  over  the  last 
decade  has  largely  been  driven  by  computer  security  commu¬ 
nity  needs.  The  positive  impact  has  been  the  development  of  a 
number  of  prototype  and  operational  systems  with  formal 
specifications  of  their  security  related  properties  and  mechani¬ 
cal  proofs  of  consistency  of  specifications  with  respect  to  the 
security  properties.  The  computer  security  community  has 
also  funded  the  development  of  several  verification  environ¬ 
ments  that  arc  largely  still  experimental.  This  current  genera¬ 
tion  of  verifiv  .ion  technology  cannot  in  its  current  form  be 
applied  to  large  scale  systems  nor  is  it  considered  staie-of-the- 
practice  by  software  developers.  This  is  in  large  part  because 
the  verification  tools  and  techniques  have  not  been  integrated 
into  the  sofiware  development  process.  Although  it  would 
seem  that  this  integration  should  occur  naturally,  it  has  not  yet 
occurred.  The  U.S.  verification  community  has  also,  until  re¬ 
cently,  ignored  Ada  verification  issues. 

The  software  engineering  community  has  focused  on  the 
software  development  life  cycle  (methods  and  tools)  and  has 
largely  ignored  the  needs  o!  software  development  for  trusted 
systems.  Research  efforts  have  addressed  new  process  models 
and  alternative  development  paradigms  such  as  those  based 
on  risk  analysis,  automatic  programming,  rapid  prototyping, 
program  transformations  and  knowledge-based  software  assis¬ 
tant  capabilities.  Important  software  engineering  issues  such 
as  accommodating  families  of  systems,  prototyping  of  key  sys¬ 
tem  capabilities,  reuse  of  previous  software  and  scaling  up  to 
very  large  systems  are  equally  important  for  trusted  systems 
yet  they  have  not  been  addressed  in  that  context.  Issues  relat¬ 
ing  to  Ada  (e.g.  Ada  process  model,  software  reuse  in  Ada, 
...)  arc  also  a  current  focus  of  attention.  Integration  of  the 
computer  security  and  formal  methods  technology  in  the  con¬ 
text  of  a  sound  software  engineering  paradigm  is  a  critical 
research  need  to  address  the  problem  of  trusted  system  devel¬ 
opment. 

The  software  environment  community  has  focused  on  the 
development  of  integrated  software  development  environ¬ 
ments  but  has  not  involved  the  integration  of  formal  specifica¬ 
tion  and  verifii  ution  tools  into  such  environments.  Since 
environments  are  to  provide  automated  support  to  the  devel¬ 
opment  and  analysis  of  complex  Defense  systems,  if  the  tar¬ 
get  system  has  trust  requirements,  the  ability  to  analyze  a 
system’s  behavior  through  formal  and  informal  means  is 
critical.  This  means  that  an  environment  needs  to  provide  a 
spectrum  of  analysis  tools  which  include  the  appropriate,  inte¬ 
grated  role  for  verification  tools.  This  integration  has  not  been 
an  area  of  co  •■centration  for  the  software  environment  com¬ 
munity.  With  the  advent  nf  Ada  for  DoD  mission-critical  sys¬ 
tems,  we  have  an  opportunity  to  focus  attention  on  a  next 
generation  Ada  environment  that  would  support  trusted  sys¬ 
tem  development. 
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RECOMMENDATIONS 

Since  the  trust  issues  raised  here  have  the  potential  for 
having  unwieldy  or  complex  solutions,  the  challenge  for  the 
research  community  is  to  be  able  to  aim  for  long  term  goals 
while  simultaneously  seeking  near-term  and  intermediate  re¬ 
sults.  Results  need  to  be  realized  in  worked  examples  which 
drive  and  focus  the  research  as  well  as  paper  studies,  since 
theoty  is  often  changed  in  the  execution  of  the  ideas. 

Progress  toward  goals  could  take  place  in  two  environ¬ 
ments.  The  first  is  to  have  research  in  a  laboratory  environ¬ 
ment  where  the  integration  of  the  technologies  can  be 
attempted  in  worked  prototype  examples  which  would  be 
scaled  up  later  in  operational  systems  if  they  prove  fruitful. 
The  second  is  to  attempt  limited  integration  in  actual  opera¬ 
tional  system  development.  A  valuable  initial  step  would  be  to 
hold  a  workshop  or  summer  study  on  future  trusted  systems 
development.  This  would  bring  together  key  contributing  tech¬ 
nologists  from  the  computer  security,  formal  verification,  soft¬ 
ware  engineering  and  software  environments  communities  and 
focus  on  integrating  appropriate  aspects  of  their  work  and 
identifying  gaps  in  the  research  to  be  funded. 

Research  areas  and  directions  for  studies  and  prototype 
developments  that  we  have  identified  include  the  following: 

•  Establishment  of  a  framework  for  modeling  and  develop¬ 
ment  of  trusted  systems  including  developmeni/inlerpreta- 
tion  of  evaluation  criteria  for  software  environments  for 
trusted  systems. 

•  investigation  of  trust  issues  (security,  integrity,  assurance) 
with  respect  to  Ada  trusted  system  development  including 
impact  on  development  paradigm  and  support  environ¬ 
ment  architecture  and  tools. 

•  Research  to  develop  a  next  generation  process  model  for 
trusted  systems  that  integrates  the  appropriate  contributing 
technologies. 

•  Prototype  development  of  “trustworthy”  automated  sup¬ 
port  environment  for  the  next  generation  process  model 


for  trusted  systems. 

Demonstration  of  applicability  of  the  new  process  model 
and  environment  on  a  set  of  high  impact  worked  exam¬ 
ples 

Several  of  these  research  directions  are  long-range  projects 
spanning  five  years  or  more  but  near-term  and  interim  results 
can  be  achieved  and  be  made  known  in  a  broad  community. 
We  can  have  a  positive  impact  on  DoD  trusted  system  require¬ 
ments  by  leveraging  and  combining  several  contributing  tech¬ 
nologies  today. 
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1.  Introduction 

In  his  108-1  Turing  Award  l,eelure[lj,  Ken  Thompson 
described  a  sophisticated  Trojan  horse  attack  on  a 
compiler,  one  that  is  undetectable  by  any  search  of  the 
compiler  source  code.  The  object  of  the  compiler  Tro¬ 
jan  horse  is  to  modify  the  semantics  of  the  high  order 
language  in  a  way  that  breaks  the  security  of  a  trusted 
system  generated  by  the  compiler. 

The  Trojan  horse  Thompson  described  is  n  form  of 
virus,  inasmuch  as  it  is  self-reproducing,  but  it  has 
other  characteristics  that  diHercnliate  it  from  viruses 
that  exploit  the  implementation  details  of  a  computer 
system,  h  irst  of  all.  t lie  sell-reproduction  is  symbiotic, 
that  is.  the  Trojan  horse  depends  on  the  source  text  of 
the  legitimate  compilin'  for  its  continued  existence. 
The  virus  only  reproduces  itself  in  the  output  stream 
of  the  compiler,  when  i he  compiler  is  compiling  itself 
(thus  destroying  the  original  virus).  A  second 
dill'erenco  is  the  relative  portability  of  the  virus  to 
(lillereiil  system.".  The  compiler  Trojan  horse  Thomp¬ 
son  described  is  less  dependent  oil  the  design  details  of 
a  particular  machine  because  it  exploits  t.he  portability 
of  high  order  languages.  A  I i tml  dill’erenco  is  the  loca¬ 
tion  of  llii1  virus  in  the  executable  file.  The  compiler 
Trojan  horse  is  inserted  in  a  place  that  is  hard  to 
search,  that  is  in  ittid-lile.  While  this  is  possible  for 
any  form  of  virus,  it  is  more  difiicull  for  viruses  that 
do  not  have  the  compiler's  internal  functions  at  their 
disposal. 

In  his  lecture.  Thompson  asserted  that  "no  amount  of 
source-level  verification  or  scrutiny  will  protect  you 
from  using  untrnsted  code."  When  no  other  means  are 
used  to  provide  assmauee,  this  is  true.  However,  this 
paper  describes  a  technique  that,  will  remove  such  Tro¬ 
jan  horses  when  used  in  conjunction  with  high-order 


language  source  code  analysis. 

This  paper  does  not  address  what  is  referred  to  here  as 
a  general  inrun,  (hat  is.  one  that  infects  programs  by 
direct  modilii-aliou  of  their  images  on  disk  (or  oilier 
secondary  storage).  The  general  virus  is  a  much  larger 
problem:  for  example,  detection  of  arbitrary  general 
viruses  is  undeeidnblc[2]. 

Section  2  of  this  paper  explains  why  this  class  of  Tro¬ 
jan  horse  and  virus  is  important  for  trusted  systems. 
Section  8  describes  the  basic  compiler  Trojan  horse, 
and  Section  -I  describes  (lie  defense  in  detail.  Section  b 
gives  a  brief  sketch  of  some  possible  measures  and 
countermeasures.  The  paper  concludes  with  some  pos¬ 
sible  applications  of  this  technique  to  building  trusted 
systems. 


2.  The  Importance  of  Compiler  Trojan  Horse 
Viruses 

Compiler  Trojan  horses  that  arc  based  on  a  symbiotic 
relationship  between  the  source  code  mid  the  binary 
code  of  the  same  compiler  are  important  for  several 
reasons  besides  the  dillicnilv  of  detecting  such  a  Tro¬ 
jan  horse.  Such  a  Trojan  horse  can  compromise  the 
security  of  many  systems  without  propagating  itself  to 
l  hose  systems,  it  can  compromise  several  classes  of  sys¬ 
tems  without  redesign,  and  it  is  dillieull  to  locale  in  an 
executable-  lile. 

The  compiler  'Trojan  horse  can  introduce  unauthorized 
byptisses  of  security  mechanisms  into  trusted  systems, 
yet.  never  exist  on  those  systems.  If  such  a  'Trojan 
horse  is  successfully  installed  on  a  development  system, 
it-  can  infect  every  system  ever  developed  t  here.  It  can 
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do  this  Ix’t-jiifv'  the  compiler  will  generate  security 
Haws  in  every  iru-ted  system  it  generates  code  lor, 
whether  it  is  compiling  for  its  own  host  or  some  other 
system. 

I 'iilil- e  the  general  virus,  the  compiler  Trojtin  horse 
virus  does  not  depend  on  low  level  imichinc  or  operat¬ 
ing  ssstetn  dependent  details  0f  the  implementi'tion  il 
infects.  One  of  the  subtleties  of  Thompson's  design  is 
the  Use  of  the  compiler's  code  generator  to  install  the 
liimtry  version  of  the  viruses.  If  the  Trojtin  horse  virus 
is  ci'ented  in  the  snnie  intermediate  language  that  is 
passed  to  tlte  code  generator,  il  will  lie  appropriately 
translated,  linked,  and  loaded  for  whatever  machine 
tie1  compiler  is  targeted  for.  This  applies  not  only  to 
the  self-reproducing  or  viral  component,  it  also  applies 
to  the  other  malicious  code  that  may  he  installed  by 
t  oe  Trojan  horse. 

The  compiler  Trojan  horse  virus  can  easily  install  itself 
ill  the  middle  of  the  disk  image  of  program,  because 
the  compiler  in-cris  it  as  it  generates  code.  A  general 
V  if  Its  call  lie  inserted  into  the  middle  of  the  disk  image 
of  a  program  loo.  Inn  tin  problem  is  more  dillicult  for 
the  general  virus.  In  the  latter  ease,  the  virus  must  lie 
designed  to  obtain  pr'u  ilege--  that  permit  il  to  modify 
the  disk  images  of  programs.  It  must  also  lie  designed 
to  perform  link  editing  curreeilv .  a  non-l  riv  ini  task 
when  the  program  di-k  image  is  hi  line  editor  output 
•'urinal . 

\ li  assertion  that  general  viruses  cautiol  insert  them¬ 
selves  in  mid-program  would  lie  untrue.  Nevertheless, 
it  i-  'ignilieniil  |y  more  dillicult  to  create  such  a  general 
vim-  and  each  cop.v  of  the  general  .inis  must  contain 
all  the  code  ncces-ary  for  correct  mid-program  iii'or- 
i  ion. 

3.  The  Trojan  Horse 

The  compiler  Trojan  hor-e  i-  introduced  into  the  sys¬ 
tem  by  a  procedure  that  resembles  a  compiler  compil¬ 
ing  itself.  The  ant hori/ed  Trojnn-horse-IYec  version  of 
the  compiler  is  used  to  compile  a  Trojan  hor.se  version 
of  itself  that  always  reproduces  the  Trojan  horse  in  the 
compiler,  l  or  this  to  occur,  there  must  hr  at  least  one 
read  access  to  'lie  legitimate  compiler  source  code,  one 
or  more  execute  accesses  to  the  compiler  (even  viruses 
1  ll list  lie  debugged),  and  ill  least  one  w  rite  access  to  the 
legitimate  compiler  binary.  None  of  these  accesses 
must  neee.ssarib  occur  on  the  'time  system. 

I  lie  compiler  Trojan  horse  is  created  as  follows: 

I  I  a  source  code  version  of  the  compiler  is 
written  that  includes  two  Trojan  hot  si’  capa¬ 
bilities.  a  security  mechanism  bypass  and  a 
self-reproducing  feat nre. 


2)  the  legitimate  Trojan  horse  free  version  of 
the  compiler  is  used  to  produce  an  object  code 
version  of  the  Trojan  horse  compiler,  and 

3)  the  Trojan  horse  object  code  version  is 
installed  over  the  legitimate  objeet  code  ver¬ 
sion  of  the  compiler. 

At  the  end  of  this  process  the  source  code  of  the  com¬ 
piler  is  free  of  Trojan  horses  but  the  executable  file  has 
two  Trojan  horse  features.  The  first  Trojan  horse 
feature  adds  unauthorized  security  mechanism 
bypasses  whenever  it  compiles  the  appropriate  source 
code.  The  second  Trojan  horse  feature  reinserts  the 
object  code  of  the  Trojan  horse1  into  the  compiler 
whenever  it  compiles  the  legitimate  compiler  source 
code.  The  Trojan  horse  objeet  code  will  remain  in  the 
system  undetected  by  any  analysis  of  the  high  order 
language  source  code  of  the  compiler.  Additionally, 
targeted  security  mechanisms  generated  by  this  com¬ 
piler  will  have  unauthorized  and  undetected  bypasses 
iti-t  ailed. 

'I’liis  attack  destroys  the  semantics  of  high  order 
languages  and  undermines  tn  >1  in  assurance  measures 
that  depend  on  them.  This  threat  is  a  serious  problem 
because  many  valuable  assurance  techniques  depend 
oil  high  order  language  semantics.  The  availability  of 
a  technique  for  ensuring  that  the  semantics  of  a  high 
order  language  are  free  of  such  problems  is  essential  for 
trust  in  high  onh  '-tiiguage  assurance  techniques. 

4.  The  Defensive  Technique 

The  defense  against  this  attack  is  based  on  the  same 
concept  of  a  compiler  compiling  itself.  The  defense 
exploits  the  symbiotic  relationship  between  the  source 
text  of  the  legitimate  compiler  and  the  self-reproducing 
feature  of  the  Trojan  horse  object  eodejfi). 

The  Trojan  horse  reproduces  itself  whenever  it  coin- 
piles  the  compiler.  To  do  this,  it  must  first  recognize 
some  key  portion(s)  of  the  source  text  of  the  legitimate 
compiler.  If  the  Trojan  horse  compiler  compiles  a 
compiler  that  >(  cannot,  identify  as  such.  it.  will  not 
reproduce  in  that  program's  object  code.  If  the 
suspect  compiler  is  led  a  disguised  version  of  itself,  or  a 
simple  temporary  compiler  of  a  clill'ereut  design,  it  will 
not  reproduce  any  such  Trojan  horses. 

If  the  legitimate  compiler  can  be  hidden  from  its  Tro¬ 
jan  horse  symbiont,  so  to  speak,  the  Trojan  horse  will 
be  erased  by  itself.  Since  it-  will  not  reproduce  and  the 
object  code  generated  by  the  disguised  compiler  will  be 
used  in  all  future  compilations,  the  threat  is  removed. 

Hiding  the  legitimate  compiler  is  not  necessarily  sim¬ 
ple.  First,  recognition  of  an  arbitrary  compiler  from 
an  analysis  f by  the  Trojan  horse)  of  the  function  of  the 
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program  can  lie  ruled  on  I  ns  beyond  the  state  of  the* 
:i rt .  However.  t In*  Troj:m  horse  has  iii.'iiiy  clues  its 
dispo-.nl  within  tin*  supcrlieial  loti  I  tiros  of  (In*  legitimate 
sonroo  toxi.  If.  for  oxnmplo.  ovory  idculilier  was 
scrambled,  tin*  Trojan  horse*  still  might  detect  a  pal- 
lorn  in  the*  keywords  of  flu*  compiler  source.  If  these 
wore  scrambled  too  (I his  is  not  dillicult  on  many  com¬ 
pilers),  the  Trojan  horse  could  analyze  comments,  con¬ 
stant  strings  (such  as  "('  Compiler.  Version  H.7". 
requests  for  library  units,  or  error  messages  (c.g.,  the 
C  compiler  is  the  only  one  with  li)8  error  messages). 

Willi  careful  analysis  and  design  |l>y  the  defeneleTs).  a 
reduced  function  compiler  could  he  created,  one  that 
even  incorporated  large  amonn's  of  code  that  had 
nothing  to  do  with  compilation.  This  temporary  com¬ 
piler  would  he  compiled  lirsl,  and  then  its  Trojan 
horse  free  object  code  version  used  to  compile  the 
undisguised  legitimate  compiler.  An  integrated  editor, 
compiler,  and  link  editor  that  can  .scramble  and 
nnseramble  program  text  as  appropriate  would  he  a 
wry  useful  .npplientioii  of  this  technique. 

5.  Measures  and  Countermeasures 
Then*  are  compiler  Trojan  horse  measures  beyond  the 
tc.xt  string  searches  mentioned  above.  Three  measures 
I luil  are  of  praetieal  significance  are.  in  increasing 
order  of  ell'ecli wiles-,  for  the  Trojan  horse; 

I)  at  tempt  to  recognize  the  compiler  by  its 

function. 

-)  make  the  Trojan  horse  part  of  I  Ik* 

compiler’s  legitimate  features. 

•'))  extend  I  lie  symbiosis, 

Tin*  following  discussion  explains  each  measure  and 
proposes  a  countermeasure  to  meet  it. 

5.1.  Recognizing  the  Function  ol*  the  Legiti¬ 
mate  Compiler 

While  i he  problem  of  recognizing  the  function  of  an 
arhiimry  program  is  not  decidable,  it  is  possible  for  the 
Trojan  horse  to  recognize  the  fund  ion  or  a  key  pari  of 
the  function  of  a  restricted  class  of  compilers.  |!y 
making  simplifying  assumptions,  the  Trojan  horse  can 
si  ill  identify  the  legitimate  compiler.  An  example  of 
such  an  assumption  is  to  assume  the  compiler  will  he 
generated  by  compiler  construction  tools.  The  output 
of  a  lexical  analyzer  generator  or  a  compiler  compiler 
contains  regular  patterns  of  instructions  and  data  that 
could  he  associated  with  the  tool  and  its  target  pro¬ 
gram. 

The  eon  liter  measure  to  this  approach  is  to  construct  a 
very  simple  hut  extremely  modular  compiler  by  hand. 
This  compiler  could  employ  techniques  not.  used  in 


compiler  construction  tools  to  complicate  tin*  detection 
problem.  If  this  compiler  is  also  divide:!  into  very 
small  modules  in  separately  compiled  source  liles,  the 
Trojan  horse  will  newr  have  enough  .source  text  to 
identify  the  compiler  function. 

5.2.  Installing  the  Trojan  Horse  in  a  Compiler 
Feature 

One  measure  mentioned  in(.'5j  is  to  incorporate  part  of 
the  compiler  function  into  the  Trojan  horse.  When 
the  Trojan  horse  is  removed  by  recompilation,  no  com¬ 
piler  on  the  system  will  work.  A  good  concrete  exam¬ 
ple  of  this  is  the  run  time  support  for  the  language.  If 
the  'Trojan  horse  is  placed  in  the  object  code  of  the*  tun 
Too  -tippor!  mechanism  of  the  language  in  such  a  way 
that  it  performs  some  of  the  run  lime  support,  it  can¬ 
not  be  removed  without  breaking  tin*  language. 

Any  practical  plan  for  disguising  it  compiler  must  take 
a  system  view  of  ihe  entire  language,  Many  languages 
assume  the  existence  of  support  mechanisms  that  are 
outside  the  deliuilioli  of  the  language  or  are  not  part  of 
the  compiler  program.  'These  support  mechanisms  cun 
be  suitable  targets  Ibi  I  he  compiler  'Trajan  horse,  so 
this  defensive  technique  should  be  applied  to  them 
also. 

5.3.  Extending  the  Symbiosis  of  the  Trojan 
Horse 

'The  linal  and  most  elfective  measure  for  the  'Trojan 
horse  is  to  extend  the  symbiosis.  As  originally  delined. 
tin*  Trojan  horse  is  a  symbiotic  system  when*  the  legi¬ 
timate  compiler  source  text  is  necessary  for  (lie  contin¬ 
ued  existence  of  the  object  code  vims.  If  n  general 
vims  is  added  as  an  additional  symbiotic  feature,  the 
total  'Trojan  horse  system  becomes  a  general  virus  with 
limited  compiler  Trojan  horse  capabilities,  since  the 
security  mechanism  bypass  feature  is  still  portable. 

In  till*  original  case,  if  ihe  object  code  of  the  compiler 
was  modilied  without  including  the  symbiotic  self- 
reproducing  feature.  the  compiler  Trojan  horse  would 
he  destroyed  when  the  compiler  was  recompiled,  How¬ 
ever.  in  the  original  ease,  Ihe  compiler  Trojan  horse 
with  the  self-reproducing  feature  is  protected  by  its 
relationship  to  tin  compilers  legitimate  source:  when¬ 
ever  the  'Trojan  horse  delects  the  compiler  in  its  own 
input,  it  reproduces. 

In  the  ease  of  (lie  third  measure,  extending  the  sym¬ 
biosis.  (he  compiler  Trojan  horse  system  is  expanded 
to  include  a  general  virus  that  resides  at  the  start  of 
some  other  program.  'That  general  virus  component 
can  then  protect  die  original  compiler  'Trojan  horse, 
'i’o  do  this,  ihe  general  virus  modifies  the  source  of  the 
compiler  to  include  I  he  compiler  'Trojan  horse,  recom¬ 
piles  il,  and  deletes  I  lie  modilied  source  lilt*.  All  of  this 
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can  lie  done  in  background  inode,  in  such  :i  way  dial 
(■lie  original  compiler  source  is  not  modilied.  only  a 
cops  of  it.  The  Trojan  horse  in  die  compiler  can 
check  selected  executable  lilcs  to  see  if  its  symbiont 
general  virus  is  there,  ami  if  not.  restore  it.  Thus  both 
virus  and  compiler  Trojan  horse  would  exist  in  mutu¬ 
ally  reinforcing  positions  on  an  infected  system. 

The  third  measure'  results  in  a  general  virus,  that  is. 
the  resulting  T  renin  horse  is  m>  longer  strictly  in  the 
class  addressed  by  this  icchni<|iic.  The  offending 
program  gives  up  portability  and  relative  simplicity  for 
an  increased  likelihood  of  survival  on  a  single  hardware 
base’.  Il  increases  its  (  bailees  of  survival  by  establish¬ 
ing  a  symbiont  that  will  not  be  overwritten  when  the 
compiler  is  recompiled. 

Nevertheless,  the  defensive  leebliicpie  of  disguising  the 
legitimate  compiler  will  present  the  symbiotic  general 
virus  with  the  same  problem.  The  general  virus  must 
also  identify  the  source  text  by  the  same  means  as  its 
partner  within  the  compiler  object  code.  If  die  com¬ 
piler  has  lice'll  successfully  disguised,  it  will  he  equally 
protected  from  both  the  original  Trojan  horse'  and  any 
symbiotic  extensions  that  must  identify  the  compiler, 
llowi'vcr.  the  disguise'  livhhii|i|i'  must  now  lie  in  ellccl 
at  all  times,  and  furthermore,  all  source  lili's  must  be 
disguise'll  in  nddidoii  to  the  compiler. 

<!.  Conclusions 

In  general,  litis  icrlmiquc  increases  die  complexity  of 
the  problem  facing  a  compiler  Trojan  horse.  A  more 
complex  compiler  Trojan  Imrse  is  more  likely  to  have 
errors,  il  will  take  longer  to  design,  develop,  and  lest, 
and  it  will  probably  he ’easier  to  delect  because  it  is 
larger.  I 'sc  oMIiis  technique  makes  the  outcome  of 
such  an  attack  depend  more  on  personal  skill  and  less 
on  system  leal  lire's. 

Tile  li'cliniquc  call  III'  applied  with  \al'\illg  amounts  of 
resources  and  achieve  reasonably  proportionate 
assurance'  results.  A  Ion  resource  approach  would 
mereb  scramble  idcnlilicrs  and  constants  before 
recompiling  the  compiler,  while  a  high  resource 
approach  wouhl  be  a  programming  system  that  rniii- 
plete'ly  hid  all  of  its  di-la.  lit  the  latter  ease,  vendors 
could  have  such  systems  independently  verilicd. 

This  technique  is  appropriate  for  very  high  assurance 
sysli'iiis  (<'.g.  beyond  Al)  where  every  available  defen¬ 
sive  measure'  is  desired.  A  high  assurance  version  of 
this  lc'('hnii|tie  should  be  supported  by  a  misled 
development  environment  and  additional  measures  to 
intended  to  cope  with  general  \  iruscs[  1. bj. 

The  technique  is  also  appropriate  r  some  systems  of 
moderate  assurance,  depending  on  their  design. 


Moderate  assurance  systems  may  contain  components 
that  arc  very  vulnerable  to  Trojan  horse  attacks.  Con¬ 
sideration  should  be  given  to  using  a  low  resource  ver¬ 
sion  of  this  technique  to  provide'  some  assurance  that, 
the'  development-  system  lias  not.  introduced  a  Trojan 
horse. 

A  final  practical  issue  is  the  examination  of  the  high 
order  language  source  for  tin*  compiler.  The  technique 
described  in  this  paper  assumes  that  there  is  no  Trojan 
horse  in  the  source  text  of  the  compiler.  This  assump¬ 
tion  may  bo  dillietill  to  moot  for  two  reasons.  First, 
f  lic  source  code  for  a  compiler  is  usually  very  closely 
held  by  (lie  compiler  vendor.  This  raises  the  question 
of  ccrtilicat-iou  and  of  publicly  available  source'  text  for 
temporary  filler  compilers:  both  are  beyond  the  scope' 
of  this  paper.  Second,  contrary  to  the sliitomont.  in  |l], 
the  task  of  insuring  that  the  compiler  source  code  is 
trustworthy  is  lion-trivial.  [examination  of  compiler 
source  code  is  probably  the  lirst.  use  flint  should  be' 
made  of  practical  automated  high  order  language 
analysis  techniques.  Since  the  compiler  source  code'  is 
the  most  sensitive  source  code  associat'd  with  the  crea¬ 
tion  of  a  trusted  system,  it  should  be  the  most 
profit  able'  place  to  look  for  high  order  language  secu¬ 
rity  Haws, 
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Abstract!  Operational  experience  with  a  taotioal 
Army  system  illustrates  the  need  for  computer 
security  safeguards.  Taotioal  environments  oan 
require  group  userids  and  distributed  control  over 
security  management  and  operation.  Careful  security 
management  planning  is  oritical.  Overrun  protection 
might  be  needed,  Penetrators  oan  exist  within  mili¬ 
tary  networks. 


INTRODUCTION* 

The  new  generation  of  Department  of  Defense 
(DoD)  computer  security  (COMPUSEC)  policy  does  not 
explicitly  address  taotioal  systems’ ' 3.  This  Is 
sometimes  understood  as  implying  that  the  policies  do 
not  apply  to  tactical  systems  or  that  they  need  to  be 
" intarnreted"  for  tactical  systems,  in  the  same  way 
tint,  the  Trusted  Network  Interpretation  Interprets 
the  Orange  Book  for  application  to  networks  l!»^. 
Furthermore,  in  the  field,  there  is  often  a  belief 
that  COMPUSEC  safeguards  are  unnecessary  for  taotioal 
systems,  and  that  physical  and  communications 
security  provide  sufficient  proteotion.  Some  tac¬ 
tical  systems  thus  have  little  or  no  COMPUSEC 
protection. 

Thi3  paper  examines  COMPUSEC  requirements  for 
one  tactical  Army  system,  based  upon  analysis  and 
experiences  in  acquiring  and  operating  the  system. 

The  paper  reaffirms  that  COMPUSEC  safeguards  are 
indeed  required.  In  fact,  the  incidents  reported  in 
this  paper  (e.g.,  a  DoD  penetrator)  made  system  users 
into  a  community  of  COMPUSEC  believers,  and  might  be 
of  similar  benefit  to  users  of  other  systems.  A 
further  conclusion  is  that,  for  the  system  examined, 
the  Orange  Book  and  its  companion  documents  are 
valid,  but  that  supplementary  guidance  is  desirable 
on  COMPUSEC  management  and  operation  in  tactical 
situations. 

The  overall  purposes  of  this  paper  are  to  focus 
more  attention  on  field  COMPUSEC  needs  and  to  provide 
motivation  for  Improving  field  practices. 


SYSTEM  DESCRIPTION 

The  Army  system  from  which  the  observations  in 
this  paper  were  drawn  is  a  Command  and  Control  (C^) 
system  being  fielded  in  USAREUR.  Initial  operation 
was  in  February  1987.  The  system  has  since  grown 
rapidly  into  a  network. 

By  Spring  1988,  the  system  included  63  user  com¬ 
puters  operating  at  about  25  sites  in  f i' e  European 


•This  paper  is  derived  from  work  performed  under 
contract  F19628-86-C-0001  for  the  United  States  Army, 
Europe  (USAREUR),  Office  of  the  Deputy  Chief  of  Staff 
for  Operations. 


countries.  At  all  sites  the  computers  are  intercon¬ 
nected  via  fiber  optic  Local  Area  Networks  (LANs).  A 
Wide  Area  Network  (WAN)  backbone  is  provided  by  four 
transportable  Defense  Data  Network-compatible  packet 
switching  nodes.  While  the  entire  interconnected  net¬ 
work  is  operational  only  during  exerol3es,  an 
increasing  percentage  is  used  for  normal  day-to-day 
operation. 

The  most  Important  function  provided  is  electro¬ 
nic  mail,  which  has  been  adapted  into  a  message  ser¬ 
vice  employing  preformatted  messages.  The  system 
also  provides  word  processing,  a  spreadsheet,  and  a 
Data  Base  Management  System  (DBRS).  The  DBMS  is 
being  used  in  a  distributed  fashion,  with  numerous 
applications  built  upon  it. 

The  system  processes  classified  data.  Operation 
began  in  the  dedicated  security  mode  of  operation  and 
is  evolving  to  the  system  high  seourity  mode  of 
operation '. 

.Security  requirements  for  the  system  were 
thoroughly  defined,  and  the  system  was  acquired  with 
the  necessary  security  foundation.  The  seourity 
safeguards  were  phased  into  use  gradually,  in  order 
to  reduoe  system  management  oomplexlty  and  avoid 
denials  of  servioe,  while  learning  how  best  to  employ 
the  safeguards.  This  approach  ha3  provided  insights 
on  operation  with  and  without  safeguards  and  on  phas¬ 
ing  the  safeguards  into  use. 


TACTICAL  REQUIREMENTS 

From  the  above  description,  the  system  might  not 
appear  to  be  tactical.  In  fact,  it  is  one  of  the 
increasing  number  of  DoD  systems  that  must  support 
both  non-taotical  operation  (for  routine  peacetime 
work)  and  tactical  operation  (for  exercises  and 
wartime).  This  section  identifies  system  require¬ 
ments  that  characterize  the  tactical  environment  and 
that  have  influenced  COMPUSEC  requirements  for  the 
system.  The  taotioal  environment  has  many 
distinguishing  requirements  (e.g.,  pertaining  to 
oommunioations,  power,  weight,  durability,  and  ease 
of  use)  that  greatly  influenoe  system  definition  and 
use)  the  foous  of  this  paper  is  on  COMPUSEC 
requirements.  The  system,  then,  must  meet  the 
following  requirements! 

o  Be  transportable)  support  multiple  moves  on 
short  notice.  (Many  sites  move  during  exer¬ 
cises)  some  sites  move  several  times  during 
an  exeroiae.) 

o  Support  roles  and  functions  that  exist  only 
in  exorcises  and  wartime,  as  well  us  roles 
and  functions  that  exist  during  peaoetime 
only  or  during  both  peacetime  and  wartime. 
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o  Support  a  hastily  assembled  and  rapidly  chang¬ 
ing  user  community, 

o  Be  survivable;  operate  despite  a  high  rate  of 
system  and  communication  failures. 

o  Operate  using  only  300-3AOO  Hertz  uncon¬ 
ditioned  voiee  channels  for  remote 
connections. 

o  Defend  against  violations  resulting  from  site 
overrun. 

The  remainder  of  this  paper  examines  COMPUSEC  require¬ 
ments  in  light  of  these  taotical  requirements. 


AUTHENTICATION 

Many  tactical  systems  do  not  use  passwords.  The 
USAREtlR  system  also  was  initially  fielded  without 
passwords,  but  passwords  wore  found  to  be  necessary. 
Furthermore,  a  numhor  of  users  requested  a  password 
capability,  Passwords  have  since  been  added  to  the 
system. 

Army  Regulation  380-380  stresses  the  desirabi¬ 
lity  of  using  Individual  userids'.  Although  the 
system  has  phased  in  passwords,  individual  userids 
are  not  used,  since  Individual  userids  cun  be  dif¬ 
ficult  to  use  in  tactical  environments.  There  are 
several  reasons t 

o  People  often  work  In  teams,  sharing  tho  use 
of  workstations,  such  that  it  would  be  unac¬ 
ceptably  cumbersome  and  time  consuming  for 
Individual  users  to  log  in  and  out,  espe¬ 
cially  if  it  is  necessary  each  time  to  return 
the  system  to  its  pre-login  operating  state. 

o  The  user  community  often  is  hastily  assembled 
and  changes  rapidly,  making  userid  and 
password  management  difficult,  especially  in 
a  crisis  environment. 

For  those  reasons,  group  usnrid3  are  used  in 
exercises,  and  would  be  in  wartime  as  well.  For 
peacetime  operation,  however,  consideration  is  being 
given  to  evolving  to  individual  userids,  because  of 
needs  for  improved  control  and  for  individual 
accountability.  Systems  such  as  this  one  that  sup¬ 
port  both  peacetime  (non-taotical)  nnd 
oxorcise/wartime  operation  thus  might  have  to  support 
both  individual  and  group  userids.  This  does  not 
pose  technical  dif f leulties ,  since  userids  can  be 
used  to  support  either  individuals  or  groups.  The 
issue,  rather,  is  a  management  issue,  regarding  how 
userids  are  to  be  used.  Where  both  individual  and 
group  userids  are  used,  care  is  needed  in  integrating 
the  userids  with  the  system  addressing  approach 
(e.g. ,  for  mail) . 

Even  when  group  userids  are  used,  it  can  be  dif¬ 
ficult  to  prepare  and  distribute  userid  (and 
password)  tables  In  situations  where  the  user  com¬ 
munity  is  being  rapidly  assembled.  Two  types  of 
distribution  are  needed:  the  tables  must  be 
installed  (and  tailored)  on  all  appropriate  systems 
and  users  must  be  informed  of  their  userids  and 
passwords.  This  proooss  is  made  more  difficult  by 
the  use  of  classified  passwords.  In  one  1ISAREUR 
exercise,  users  at  several  sites  experienced  substan¬ 
tial  denial  of  service  due  to  delays  In  distributing 
and  Installing  userids  and  passwords. 

To  avoid  such  denial  of  service  delays,  it 
should  be  possible  to  create  and  manage  U3erids  and 


passwords  in  a  distributed  manner,  without  reliance 
on  a  remote  central  site.  This  distributed  manage¬ 
ment  also  creates  a  need  for  a  network-wide  userid 
naming  convent ion,  to  ensure  that  userids  are  unique. 
Of  course,  in  avoiding  denial  of  service  delays, 
there  is  also  ar.  operational  requirement  to  carefully 
plan  security  initialization  of  a  network. 

In  tactical  situations,  distributed  operation 
must  be  supported  to  the  greatest  extent  feasible, 
since  connectivity  might  not  be  available.  For 
example,  even  If  userid  creation  normally  is  done  via 
a  security  server,  it  should  be  possible  for  stand¬ 
alone  or  Isolated  workstations  to  perform  this  func¬ 
tion  when  the  server  is  unavailable.  Workstations 
should  not  be  totally  dependent  on  a  server  for  their 
security  or  operation.  A  workstation  forced  to 
operate  without  a  network  or  server  should  saorifioe 
neither  security  nor  local  operating  capability. 

Important  authentication  requirements  for 
distributed  tactical  environments  are  that  users  must 
be  capable  of  invoking  the  password  change  pnooodure 
on  demand,  and  that  security  offloer  involvement  must 
not  be  necessary.  The  reason  for  these  requirements 
is  that  users  might  quickly  have  to  change  their 
passwords  to  reaot  to  changing  tactical  situations, 
and  that  a  security  offloer  might  not  be  available  to 
issue  passwords.  Both  requirements  are  reoommended 
in  the  National  Computer  Security  Center's  (NCSC)  DoD 
Password  Management  Guideline^. 

A  final  requirement  related  to  authentication  is 
tho  need  to  authenticate  the  originator  of  trans¬ 
actions,  such  a3  messages.  Users  must  not  bo  able  to 
originate  transactions  that  appear  to  be  from  other 
users,  because  this  capability  could  be  used  to  ori¬ 
ginate  false  transactions,  which  might  cause  serious 
disruptions.  The  USAREIJR  system  has  had  one  such 
false  transaction,  and  its  defenses  have  been 
bolstered  to  prevent  reoccurrences .  Other  Theater 
systems  also  have  had  false  transactions.  On  one 
system,  a  user,  pretending  to  be  another  user,  sent 
an  insulting  E-mail  message  to  a  third  user.  The 
third  user  responded  by  returning  an  insulting  note 
to  tho  listed  originator,  who  wa3  unaware  of  the 
initial  message.  Fortunately,  the  problem  was 
identified,  and  audit  trails  enabled  identification 
of  the  culprit.  Tho  point  of  this  discussion, 
however,  is  that  the  threat  is  real  and  must  bo 
countered.  On  a  related  topic,  it  is  probably  tho 
case  that  transaction  integrity  is  more  important  in 
tactical  than  strategic  systems,  since  tactical 
systems  often  require  quicker  response  times,  and 
since  tactical  integrity  violations  might  prevent 
wnapons  strikes  or  cause  strikes  against  friendly 
forces . 


ACCESS  CONTROL 

It  is  sometimes  3ald  that  there  i3  no  need  for 
discretionary  aooess  controls  in  taotical  systems. 
That  is  not  true  for  the  USAREUR  system.  Although 
the  vast  majority  of  system  users  sees  no  need  to 
control  "read"  access  to  data,  a  small  minority  of 
users  does  require  suoh  protection.  Furthermore, 
there  is  a  strong  need  for  "write"  protection. 

During  exercises  and  wartime,  many  users  are  highly 
stressed  and  might  not  be  adequately  trained.  The 
system  must  prevent  these  users  from  accidentally 
corrupting  or  destroying  data.  Discretionary  access 
controls  help  to  provide  this  capability  by  reducing 
the  number  of  people  who  oan  change  data. 

As  was  true  for  userid  and  password  tables,  the 
most  difficult  aspect  of  managing  discretionary 
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access  controls  In  a  tactical  environment  Is  In 
ensuring  that  permissions  are  properly  set  when  a 
large  amount  of  equipment  is  initially  deployed  or 
when  a  user  community  is  hastily  assembled. 
Complicating  the  assignment  of  permissions  t.  .j  the 
facts  that  organization  structures  change  in  wartime 
and  that  people  switch  organizations,  it  la  impor¬ 
tant  that  this  aspect  of  system  operation  be 
anticipated,  taught,  and  practiced. 

During  exercises  and  wartime,  all  sites  in  the 
USAREUR  network  operate  at  the  same  security  level, 
i.e.,  the  maximum  allowable  classification  is  the 
3ame  for  nil  systems.  This  simplifies  interoperabi¬ 
lity  among  network  users.  Where  communication  out¬ 
side  "he  network  is  required  (with  systems  that 
operate  at  higher  or  lower  classification  levels), 
users  employ  a  floppy  disk  downgrade  process  similar 
to  that  described  in  the  National  Telecommunications 
and  Information  Systems  Security  (NTTSS)  Advisory 
Memorandum  on  Office  Automation  Security  Guideline”, 

During  peacetime,  many  sites  operate  at  a  dif¬ 
ferent  security  level  than  they  do  in  exercises  and 
wartime,  e.g.,  many  operate  at  the  unclassified 
level.  These  sites  require  the  capability  to  alter¬ 
nate  between  operation  at  different  security  levels, 
in  a  "periods  processing"  fashion.  This  13  one  of 
the  mo3t  important  security  requirements  and  is  espe¬ 
cially  critical  for  exercises. 

Vulnerability  to  Internal  Penetrators 

With  the  increased  use  and  size  of  networks, 
more  thought  must  he  given  to  network  security  and  to 
the  vulnerability  of  the  network  as  a  whole  to  every 
one  of  its  users.  DoD  system  managers  often  assume 
that,  because  all  users  have  security  clearances, 
there  la  no  penotrator  threat.  That  is  not  true. 

During  one  USAREUR  exercise,  1  person  caused 
significant  disruption.  This  person  was  olaared  and 
authorized  to  aeoess  portions  of  the  notwork,  but  his 
actions  exceeded  hts  authorizations.  The  Tarst 
indication  of  a  problem  came  when  a  site  received  an 
al»rt  and  found  that  its  password  table  had  been 
destroyed,  necessitating  a  lengthy  reboot,  and 
resulting  in  the  loan  of  some  data.  This  was  the 
first  of  three  such  attacks,  all  of  which  required  a 
lengthy  system  reboot. 

With  the  first  alert,  the  site  called  the  not¬ 
work  operations  center,  which  began  to  trace  the 
source  of  the  activity.  Meanwhile,  the  person  had 
broken  into  the  operating  system  of  one  of  the  two 
central  database  server's  (supporting  the  overall 
notwork),  and  twice  attempted  to  reinitialize  the 
large  har’d  disk.  Fortunately,  both  attempts  failed, 
or  substantial  amounts  of  exorcise  data  would  have 
been  lost. 

Network  operations  personnel  were  able  to  locate 
the  person,  and  the  activities  promptly  ceased.  But 
significant  disruptions  had  been  caused,  and  greater 
difficulties  had  been  only  narrowly  avoided.  The 
point  to  this  incident  13  that  the  threat  exists. 

In  this  case,  because  the  network  was  being  ini¬ 
tially  fielded,  some  of  the  internal  controls  were 
not  yet  in  place.  This  was  intentional,  to  avoid 
denial  of  service  due  to  Improperly  initialized 
security  controls.  The  particular  approaches  used  by 
the  intruder  would  not  have  worked  had  the  full 
security  defenses  been  in  place. 

Even  with  the  full  defenses,  however,  the  system 
is  vulnerable  to  knowledgeable  users.  Unlike  some 


tactical  systems,  the  USAREUR  system  is  based  on  a 
commercial  operating  system  that  is  familiar  to  many 
users  and  that  provides  rich  functionality  to  users 
who  can  penetrate  the  user  interface.  Even  were  the 
system  trusted,  vulnerability  would  remain.  This  was 
vividly  illustrated  by  the  penetration  of  the 
National  Aeronautios  and  Space  Administration  (NASA) 
Space  Physics  Applications  Network  (SPAN),  which  U303 
an  operating  system  that  has  received  a  class  CP 
rating  from  the  NCSC^.  Another  example  was  the 
penetration  during  UNIX  Expo  1987  of  Gould's 
C?-oertified  UTX/32S,  in  which  the  system  administra¬ 
tor  was  duped  into  allowing  an  intrusion”.  (Indeed, 
the  system  administrator  might  prove  bo  be  the 
Achilles'  heel  for  many  trusted  systems.) 


In  the  USAREUR  case,  as  Increased  security  is 
phased  in,  users  are  informed  of  what  Is  allowable 
and  not  allowable  and  of  the  rlsk3  they  assume  by 
being  a  member  of  the  network.  Beyond  this,  there 
are  limits  to  what  can  be  achieved.  It  is  unlikely 
that  the  risks  will  constrain  or  limit  network 
expansion.  Like  some  other  advanced  technologies, 
networks  are  volatile  tools  that  increase  both  system 
capability  and  system  vulnerability. 

Overrun  Protection 


A  final  area  of  acooss  control  in  which  tactical 
systems  warrant  special  consideration  is  overrun 
protection.  The  threat  is  that  an  enemy  might  over¬ 
run  a  site  and  access  the  data  stored  there. 

The  typical  defense  against  overrun  is  to  physi¬ 
cally  destroy  the  system  and  media.  This  is 
simplified  by  having  fewer  media  to  destroy  or  by 
selectively  destroying  only  the  most  sensitive  media 
(e.g.,  those  with  current  data  pertaining  to  many 
sites,  rathur  than  those  that  contain  only  old  audit 
data).  In  extreme  cases,  DoD  policy  is  to  use  Anti- 
compromise  Emergency  Destruct  (AGED)  devices  to 
accomplish  the  destruction9,  ACEDs  are  dangerous, 
however,  and  can  causo  substantial  damage  if  acciden¬ 
tally  activated. 

An  alternative  solution  to  destroy  data  is  to 
encrypt,  stored  data,  so  that  the  data  oan  be  rendered 
unavailable  (for  an  estimated  period  of  time)  by 
destruction  of  the  encryption  key.  This  approach  ha3 
been  considered  for  use  by  the  Department  of  State1®. 
This  approach  could  result  in  substantial  data  loss 
If  the  key  is  accidentally  destroyed,  but  a  copy  of 
the  key  oan  be  stored  at  a  3ocond  site  to  reduce  this 
risk. 


While  most  tactical  systems  probably  do  not  have 
a  sufficient  overrun  risk  to  warrant  special  protec¬ 
tion,  those  sites  that  are  at  high  risk  should 
consider  file  encryption.  The  likelihood  of  acciden¬ 
tal  destruction  must  be  anticipated  and  countered, 
however,  so  that  the  safeguard  does  not  cause  greater 
losses  than  the  threat  itself. 

A  second  throat  associated  with  overrun  is  that 
an  enemy  might  use  the  site's  people  and  equipment  to 
access  other  systems.  One  technique  that  can  be  use¬ 
ful  in  defending  against  this  threat  is  a  "dures3 
code,"  such  as  is  available  on  the  Access  Control 
Encryption  (ACE)  cards  developed  by  Security 
Dynamics.  A  duress  code  is  a  special  Personal 
Identification  Number  (PIN)  that  allows  access  but 
30ts  off  an  alarm  at  the  operator  console. 
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AUDITING 

Some  tactical  users  have  said  that  auditing 
might  be  desirable  during  peacetime  or  exercises,  but 
is  undesirable  during  wartime.  Such  users  have 
stated  that  (1)  there  would  be  no  time  to  analyze  an 
audit  trail  during  wartime,  and  (2)  removal  of 
auditing  could  increase  system  performance.  Neither 
reason  is  valid.  Audit  safeguards  serve  four  pur¬ 
poses;  surveillance,  deterrence,  damage  assessment, 
and  problem  analysis  and  resolution.  These  purposes 
are  at  least  a3  important  in  wartime  33  they  are  in 
peacetime.  In  addition,  auditing  should  be  suf¬ 
ficiently  unobtrusive  that  it  not  impede  operation, 
whether  in  peacetime  or  wartime.  There  might  be 
cases  in  which  auditing  should  be  changed  or  even 
reduced  in  wartime,  but  it  cannot  be  discarded.  Of 
course,  if  a  choice  must  be  made  between  operation 
and  security  in  tactics!  wartime  situations,  the 
choice  normally  should  be  for  operation.  For 
example,  take  the  case  of  workstations  on  a  LAN, 
where  the  workstations  regularly  forward  their  audit 
data  to  a  central  server.  If  the  server  Is  not 
available  and  audit  storage  space  is  exhausted,  the 
old  audit  data  should  be  overwritten  rather  than 
suspending  operation  for  want  of  audit  storage. 

Security  auditing  is  needed  in  tactical  systems, 
with  attention  focused  on  how  to  audit  most  effec¬ 
tively  and  efficiently.  For  example,  unless  prodi¬ 
gious  amounts  of  data  can  be  stored  and  analyzed,  the 
audit  trail  should  not  normally  compile  a  list  of  all 
authorized  user  activities  (e.g.,  file  open,  program 
initiation),  but  must  record  attempts  at  unauthorized 
activity  and  all  changes  to  security  parameters.  The 
audit  concept  cannot  assume  that  there  is  a  security 
officer  who  nits  at  a  console,  monitoring  the  system, 
or  who  has  time  to  search  .lrohivi)  audit  files 
looking  for  suspicious  activity  (although  software 
might  be  used  to  conduct  such  searohes).  Instead, 
the  concept  should  foous  on  alerts  and  reports. 

Alerts  would  be  sent  to  the  overall  system  operator 
or  system  administrator  (if  there  is  one),  who  would 
notify  a  security  officer  If  warranted.  Alerts  might 
include  such  actions  as  the  addition  of  a  new  userid 
or  the  receipt  of  a  login  from  a  user  already  logged 
in  to  another  workstation.  (In  most  oases  these 
actions  will  be  normal  and  authorized,  but  perhaps 
not  in  all  cases.)  Reports  would  be  compiled  from 
many  events  and  distributed  to  the  security  officer. 
Reports  are  useful  In  identifying  groups  of  users 
with  a  high  error  rate  (who  might  therefore  need 
guidance  or  training).  The  most  requested  report 
probablv  will  be  a  simple  daily  listing  of  who  logged 
in  and  out,  when,  and  what  external  resources  were 
accessed. 


CONCLUSIONS 

Experience  with  one  tactical  system  reaffirms 
that  computer  security  safeguards  are  needed,  not 
only  to  prevent  loss  of  sensitive  data,  but  also  to 
ensure  the  accuracy  of  data  and  transactions.  The 
required  COMPUSEC  features  for  this  tactical  system 
are  almost  Identical  to  those  for  most  strategic 
systems.  The  main  differences  are  in  how  the 
features  are  used. 

To  help  ensure  that  COMPOSED  features  are  pro¬ 
perly  used  in  tactical  systems,  the  DoD  should 
incorporate  into  overall  C0MPU5EC  policy  brief  guid¬ 
ance  on  COMPUSEC  management  and  operation  in  tactical 
environments.  AR  38O-380  already  includes  some 
tactical  COMPUSEC  guidance,  but  could  benefit  from 
expansion  to  address  points  made  in  this  paper1*. 


Furthermore,  requirements  and  procedures  that  pertain 
to  tactical  systems  should  be  incorporated  into 
Security  Features  User's  Guides,  Trusted  Facility 
Manuals,  Standard  Operating  Procedures,  and  Operating 
Concept  documents. 

Recent  improvements  in  DoD  COMPUSEC  policy  and 
technology  should  result  In  improved  DoD  security, 
but  care  must  be  taken  that  the  new  policies  and 
technologies  are  properly  applied.  This  paper  exam¬ 
ines  the  application  of  COMPUSEC  in  a  taotioal  system. 
Similar  field  reportage  should  be  encouraged  both  for 
other  tactical  systems  and  in  other  application 
areas,  so  that  empirical  data  is  used  to  validate  and 
improve  upon  our  policies  and  technologies. 


ACKNOWLEDGMENTS 

The  author  is  grateful  for  the  review  and  com¬ 
ments  provided  by  Mr.  Shel  Dick  of  Headquarters, 
USAREUR,  and  by  Dr.  John  Vasak  of  The  MITRE 
Corporation. 


REFERENCES 

[1]  DoD  Directive  5200.28  (March  1988),  "Security 
Requirements  for  Automated  Information  Systems 
(AISs),"  Deputy  Secretary  of  Defense. 

123  DoD  5200.28-STD  (December  1989),  Department  of 
Defense  Trusted  Computer  System  Evaluation 
Criteria.  Deputy  Secretary  of  Defense. 

t3l  NCSC-TG-005  (July  1987),  Trusted  Network 

Interpretation  of  the  Trusted  Computer  System _ 
Evaluation  Criteria,  National  Computer  Security 
Center. 

(M]  Army  Regulation  380-380  (March  1987), 

Automation  Security,  Headquarters,  Department 
of  the  Army. 

153  CSC-ST0-002-85  (April  1988),  Department  cf 

Defense  Password  Management  Guideline,  National 
Computer  Security  Center. 

£63  HTISSAM  COMPUSEC/ 1-87  (January  1987),  Advisory 
Memorandum  on  Office  Automation  Security 
Guideline,  National  Telecommunications  and 
Information  Systems  Security  Committee, 

National  Security  Agency. 

C7l  Marbach,  W.  D. ,  A.  Nagorski,  and  R.  Sandza  (28 
September  1987),  "Hacking  Through  NASA," 
NEWSWEEK. 

183  Smith,  K.  (February  1988),  "Tales  of  the 
Damned,"  UNIX  Review,  Vol.  5,  No.  2. 

C?3  DoD  5200, 1-R  (June  1986),  Information  Security 
Program  Regulation,  Deputy  Secretary  of 
Defense. 

t’03  McNulty,  L.  (1987),  private  coramuni cation, 
Department  of  State. 


121 


COMSEC  INTEGRATION  ALTERNATIVES 
John  Linn 

BBN  Communications  Corporation 
150  CambrldgaPark  Drive 
Cambridge,  Massachusetts  02140 


Abstract 

Encryption-based  communlcallons  security  (COMSEC)  (unctions 
cart  be  Integrated  Into  a  network  system  In  several  ways.  The  "traditional” 
approach  places  COMSEC  modules  on  a  communications  path, 
essentially  transparenl  to  the  components  communicating  across  that 
path.  An  alternates  approach  Integrates  COMSEC  functions  within  a 
Ironl  end  processor,  Interposed  on  a  communications  path  yet 
participating  In  an  explicit  host-FE  protocol  with  the  host  computer  it 
serves.  A  third  approach  positions  COMSEC  (unctions  within  a 
peripheral  operating  under  host  computer  control.  This  paper  explores 
the  Implications  of  each  approach,  with  regard  to  protocol  layer 
placement,  comprehensiveness  ot  security  services  offered,  applicability 
to  environments,  TCB  boundaries  and  evaluation  concerns, 
transparency,  several  dimensions  ol  cost,  and  the  ability  of  an  approach 
to  provide  enhanced  (unctions  in  support  of  an  associated  host 
computer. 


lnltaducllQQ 

In  order  to  achieve  a  total  Information  security  (INFQSEC)  solution 
in  a  network  environment,  communications  security  (GOMSEC)  and 
computer  security  (COMPUSEC)  techniques  must  be  combinod.  Those 
techniques  can  be  combinod  in  many  ways.  Each  COMSEC  approach 
raises  a  different  sot  of  COMPUSEC  Issues,  not  only  with  regard  to  a  host 
computer's  Internal  processing  but  also  with  regard  to  COMSEC 
component  control,  Many  COMSEC  components  incorporate  their  own 
embedded  control  processors,  raising  Internal  COMPUSEC  'ssues 
distinct  Irom  those  oi  the  host  computers  they  servo.  Some  approaches 
rely  on  host  computers  to  perform  COMSEC  control  functions  along  with 
the  user  applications  they  support.  This  paper  examines  the  Implications 
which  different  approaches  Impose,  both  on  COMSEC  component 
design  and  on  the  designs  ot  the  hosts  the  COMSEC  components 
serve. 


Figure  1  Illustrates  an  example  of  COMSEC  integration  within  a 
transparent  front  end  system.  The  host  computer  is  a  protocol  peer  with 
another  host  computer  (not  shown),  accessed  through  the  network.  The 
example  protocol  stack  shows  OSI  layers  1-3  (physical  through  network 
layers)  passed  through  the  Irani  end  to  the  network  without  encryption, 
with  layers  4  through  7  (transport  through  application)  encrypted  before 
transmission.  This  is  a  typical  protocol  layer  placement  lor  a  transparent 
FE. 


Example 

Protocol 

Stack 


Outboard  Transparent  Integration 
(Transparent  FE) 


Delin'tipfUtLAIternalKfis 

This  section  defines  throe  categories  ol  COMSEC  integration 
strategies,  informally  termed  the  transparenl  front  ond  (FE)  approach,  the 
non-transparent  FE  approach,  and  the  peripheral  approach.  The  FE 
approaches  are  distinguished  from  the  peripheral  approach  by  being 
interposed  on  a  host's  communications  path.  This  placemen!  assures 
that  no  network  communication  can  occur  except  under  security 
component  control;  all  communications  are  mediated  through  the  FE. 
The  peripheral  approach,  on  the  other  hand,  is  invoked  under  host 
control.  Its  hardware  structure  does  not  guarantee  that  security 
component  processing  Is  Invoked  on  all  communications.  The  FE 
approaches  are  distinguished  from  each  other  based  on  whether  the 
host  explicitly  requests  services  and/or  receives  results  from  ihe 
COMSEC  component,  ortho  component  acts  as  a  transparent  and  silent 
communications  partner. 

Outboard  Transparent  Integration 

In  the  outboard  transparent  Integration  approach,  an  encryption 
component  Is  interposed  on  a  computer's  communications  path  In  a 
manner  which  Is  transparent  to  the  computer.  This  allows  encryption  to 
provide  a  variety  of  security  services  without  Impact  on  existing  host 
protocol  implementations,  but  precludes  the  encryption  componenl  from 
providing  functions  which  require  explicit  Interaction  with  the  host.  As  a 
result,  the  host  computer  cannot  select  or  Influence  the  security 
functions  which  the  component  provides.  For  example,  the  set  of  OSI 
security  services  provided  by  the  component  may  be  fixed  when  the 
component  is  manufactured,  or  may  be  loaded  Into  the  component  as 
configuration  data  (with  different  choices  for  different  destinations,  If 
appropriate),  but  cannot  be  selected  dynamically  by  the  host  tor 
individual  Instances  of  communication. 


Figure  1 


Outboard  transparent  Integration  is  the  "traditional"  approach  to 
COMSEC  placement,  redacting  the  development  of  COMSEC  and 
COMPUSEC  as  distinct  disciplines  and  consideration  ol  COMSEC  as  a 
function  within  the  communications  realm  rather  than  the  subscriber 
realm.  The  choice  ol  the  term  "outboard"  to  define  this  approach  is  nol 
meant  to  Imply  that  Ihe  encryption  component  must  be  in  a  separate 
stand-alone  physical  package  from  Its  associated  host.  It  may,  for 
example,  be  a  circuit  board  which  plugs  into  a  computer's  bus.  The  salient 
characteristic  Is  that  all  network  communications  accesses  musl  traverse 
the  FE. 

In  the  past,  most  COMSEC  components  have  been  transparenl 
link  encryptors.  These  components  operate  at  the  OSI  Reference 
Model's  layer  1  or  the  lower  part  ol  layer  2,  and  treat  any  protocol  control 
information  of  layers  above  as  uninterpreted  data.  The  Internal 
processing  requirements  for  an  encryptor  operating  In  this  range  of  the 
protocol  hierarchy  are  modest.  Generally,  the  level  ot  Internal  processing 
complexity  In  a  COMSEC  component  increases  when  a  component 
operates  at  a  higher  point  in  the  protocol  hierarchy.  In  particular,  a 
transparent  COMSEC  component  operating  at  the  upper  part  ol  layer  2  or 
the  layers  above  can  be  a  significantly  complex  embedded  computer 
system.  Part  of  flte  complexity  comes  from  the  fact  that  a  transparent 
COMSEC  FE  must  duplicate  protocol  layers  already  present  within  an 
associated  host.  The  layers  below  Ihe  point  where  encryption  is 
Integrated  must  be  terminated  tram  the  host's  viewpoint  and  regenerated 
for  the  network's  benefit,  making  for  a  relatively  complex  "two-headed" 
Implementation. 
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Inboard  Integration  as  Peripheral 


Outboard  Integration  with  Host-FE  Prntnr.nl 

When  encryption  Is  Incorporated  Into  an  outboard  component 
which  participates  In  arr  explicit  protocol  with  the  host  computer  It  serves, 
different  Implications  arise.  The  host  computer  must  act  as  a  peer  In  the 
explicit  protocol,  meaning  that  the  host  computer's  software  must 
operate  differently  than  It  would  operate  If  no  encryption  component 
wore  present.  If  this  can  be  accomplished,  then  the  encryption 
component  can  provide  valuable  services  to  Its  host  which  a  transparently 
Integrated  outboard  component  cannot  offer.  As  a  special  case,  a 
non-transparent  FE  could  be  designed  In  such  a  manner  that  It  could 
operate  with  reduced  functionality  even  If  no  peer  for  the  ho$t-FE 
protocol  were  available.  Such  a  hybrid  would  operate  as  a  transparent  FE 
If  its  host  did  not  support  (he  host-FE  protocol, 

Figure  2  illustrates  an  example  of  COMSEC  integration  within  a 
non-transparent  front  end  system,  As  In  Figure  1,  the  host  computer  Is  a 
protocol  peer  wilh  another  host  computer  (not  shown),  accessed 
through  the  network.  Layers  4  through  7  of  this  traffic  are  encrypted.  In 
contrast  to  Figure  f ,  this  host  computer  also  acts  as  a  peer  with  the  local 
host-FE  protocol  module  In  the  front  end  system;  two  protocol  substacks 
from  layers  4  through  7  correspond  to  the  transit  (host-host)  and  local 
(host-FE)  paths.  In  the  example,  therefore,  demultiplexing  between 
transit  and  local  traffic  streams  Is  carried  out  using  network  layer 
mechanisms. 


Outboard  Integration  with  Host-FE  Protocol 
(Non-Transparent  FE) 

Figure  2 


There  are  many  variations  of  the  outboard  non-transparent 
approach,  distinguished  by  the  host-FE  protocol's  characteristics.  As 
with  the  outboard  transparent  Integration  approach,  the  choice  ol  the 
term  “outboard"  to  describe  the  approach  Is  not  meant  to  preclude  the 
encryption  module  from  sharing  common  physical  packaging  with  the 
host  It  serves.  One  variation  resembles  the  transparent  approach,  In  that 
the  protocol  layering  between  host  and  FE  is  the  same  as  that  between 
FE  and  network  (except  for  any  layers  added  by  the  FE  in  support  of 
COMSEC  functions).  In  this  variation,  the  host-FE  protocol  Is  used  to 
carry  information  such  as  connection  requests  and  authentication  data 
between  the  host  and  FE,  In  another  variation,  imi  lamentation  of 
protocols  below  a  given  layer  Is  delegated  to  the  FE,  Independent  of 
security  concerns,  many  communications  front  end  processors  have 
been  designed  In  this  manner  in  order  to  offload  low  layer  protocol 
processing  from  a  host;  COMSEC  Integration  within  such  a  front  end  Is  a 
natural  extension. 


When  encryption  Is  embedded  In  a  peripheral  device  operating 
under  host  software  control,  many  new  and  qualitatively  different 
functions  become  possible.  Encryption  can  be  applied  In  a  fashion 
specific  to  upper-layer  protocols  and  can  distinguish  among  Individual 
users,  The  price  for  this  flexibility  Is  a  trust  requirement  imposed  on  the 
host  directing  the  cryptographic  peripheral's  operations.  Invocation  of 
cryptographic  processing  Is  controlled  by  the  host  computer's  TCB. 
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Integration  as  Peripheral 
Figure  3 


Figure  3  Illustrates  an  example  ol  COMSEC  Integration  within  a 
cryptographic  peripheral  rather  than  a  front  end  system.  As  In  Figures  1 
and  2,  the  host  computer  Is  a  protocol  peer  with  another  host  computer 
(not  shown),  accessed  through  the  network.  Since  the  Interface 
between  the  host  and  the  peripheral  Is  a  local  matter,  no  explicit 
communications  protocol  applies  between  these  two  components.  The 
host  invokes  the  peripheral's  functions  In  order  to  provide  cryptographic 
protection  for  an  application  layer  protocol,  such  as  X.400  messaging  or 
FTAM,  While  peripheral-based  COMSEC  integration  Is  not  confined  lo 
application  layer  uses,  It  offers  a  better  approach  to  upper-layer  security 
requirements  than  front  end  approaches  can  provide. 

Cryptographic  peripherals  can  be  designed  In  various  ways, 
offering  significantly  different  service  Interfaces  to  their  associated  host 
computers.  Typically,  a  processor-less  peripheral  presents  Its  host  with 
an  Interface  which  allows  the  host  great  flexibility  In  terms  of  choice  of 
operations  but  requires  the  host  to  Interact  with  the  peripheral  at  a  low 
level.  A  peripheral  with  an  onboard  processor  can  offer  a  more 
constrained  Interface,  and  can  group  low-level  primitive  cryptographic 
functions  Into  atomic  operations.  In  all  oases,  any  unencrypted 
encryption  keys  should  be  protected  within  the  peripheral's  physical 
boundaries  and  should  not  be  accessible  to  the  host  processor.  These 
techniques  can  help  to  protect  the  Internal  Integrity  of  COMSEC 
(unctions,  While  they  reduce  Important  aspects  of  the  trust  requirements 
placed  on  the  host  processor's  TCB,  they  do  not  relieve  the  host  of 
responsibility  for  ensuring  that  COMSEC  functions  aro  Invoked  when 
appropriate,  The  host's  TCB  must  still  assure  that  data  which  should  be 
encrypted  Is  In  fact  encrypted. 
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in  a  multi-level  system,  the  input  to  an  encryption  function  often 
has  a  higher  security  level  than  the  function's  output;  appropriate  labeling 
must  be  applied  and  enforced  at  the  function's  interfaces.  In  certain 
cases,  it  may  be  feasible  and  desirable  to  enforce  labeling  conventions 
wilhin  the  peripheral's  boundary. 

Even  when  all  the  functions  associated  with  a  cryptographic 
peripheral's  outboard  processor  are  considered,  they  are  likely  to  be 
significantly  smaller  than  those  associated  with  an  FE's  processor.  No 
local  operating  system  or  communications  protocol  support  Is  ordinarily 
required.  Often,  processing  requirements  can  bo  satisfied  with  a 
microcontroller  rather  than  a  lull-lledged  processor. 


Areas  hr  Comparison 

This  section  Introduces  several  criteria  which  are  important  In 
comparing  alternative  approaches,  and  considers  the  relationship 
between  those  criteria  and  the  implementation  options. 

Protocol  Laver  Placement 

This  crilorion  measures  an  approach's  ability  to  provide  protection 
in  a  fashion  specific  to  a  broad  range  ol  protocol  layers.  While  protection 
applied  at  any  layer  provides  a  measure  ol  prolection  for  layers  above,  It 
is  nol  tailored  to  the  special  capabilities  and  needs  of  specific  protocols  at 
higher  layers  and  hence  can't  satisfy  all  security  requirements  of  a 
layered  prolocol  architecture.  For  example,  netv/ork  layer  (layer  3) 
encryption  can  prolect  the  stream  ot  traffic  between  a  pair  of  hosts,  but 
can't  distinguish  between  different  individual  users  on  those  hosts  as 
they  send  interpersonal  messages  at  the  application  layer  (layer  7). 

The  peripheral  approacli  Is  most  successful  with  regard  to  this 
criterion,  it  can  bo  applied  at  any  layer  up  to  and  including  the  application 
layer.  The  transparent  FF.  approach  is  least  succosslul,  as  it  is  generally 
difficult  to  apply  above  the  network  layer.  'Ihe  non-transparent  FE  can  bo 
applied  above  the  noiwoik  layer,  especially  if  implementation  ot  lower 
layers  is  delegated  to  the  FE,  but  cannot  bo  easily  extended  all  the  way  to 
the  application  layer 
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This  criterion  measures  an  approach's  ability  to  provide  a 
comprehensive  range  of  security  services,  While  the  sot  ol  appropriate 
functions  varies  depending  on  the  cholco  ol  prolocol  Into  which 
COMSEC  is  integrated,  some  generalizations  can  bo  made  about 
dilteront  approaches'  attributes.  To  succeed  In  this  criterion,  an 
approach  should  bo  ablo  to  provide  the  lull  range  of  OSI  security  services 
which  are  appropriate  to  its  protocol  placement. 

A  distinction  can  be  made  between  "value  added"  services  and 
services  which  restrict  a  hoat  computer's  actions. 
Administratively-directed  access  control  is  a  good  example  of  the  latter 
category.  The  FE  approaches  are  superior  to  the  peripheral  approach  in 
their  ability  '0  enforce  controls  restricting  a  host 

On  the  other  hand,  certain  services  aia  best  provided  wilhin  a  host. 
For  example,  the  non-repudiation  service  provides  message 
acccuntabilily.  A  host's  users  should  not  be  expected  to  accept 
individual  responsibility  for  an  incoming  message  merely  because  li  was 
acknowledged  by  an  FE-based  encryptor.  User-level  accountability 
should  be  based  on  a  path  extending  all  the  way  to  a  user. 

No  single  approach  is  optimal  lor  providing  all  types  of  services. 
Certain  services  are  best  provided  by  extending  the  endpoints  of 
COMSEC  protection  Into  subscriber  hosts,  most  closely  approaching  the 
hosts'  users.  Other  services  are  best  provided  by  a  device  operating 
independently  from  a  subscriber  host  and  immune  from  its  control.  In 
order  to  evaluate  an  approach  with  regard  to  service 
comprehensiveness,  one  must  first  establish  the  set  of  services  which 
are  important  In  a  given  maiket  sector. 


Applicability  to  Environments 

In  some  environments,  a  COMSEC  component's  primary  role  Is  to 
provide  value-added  security  services  when  such  services  are  requested 
by  a  subscriber  host  or  process.  Typically,  this  paradigm  is  associated 
with  unclassified  environments,  although  it  may  also  be  applicable  to 
certain  classified  contexts,  particularly  when  trust  levels  and/or  access 
class  ranges  are  uniform  within  a  network.  Such  services  are  best 
provided  by  a  peripheral  or  non-transparent  FE  COMSEC  modulo;  a 
transparent  FE,  by  Its  nature,  lacks  a  control  Interlace  through  which  an 
associated  host  computer  can  select  optional  services. 

In  other  environments,  a  COMSEC  component  assumes  an 
enforcement  filter  function,  restricting  the  actions  ol  an  associated  host 
computer  In  order  to  enforce  a  network  security  policy.  Such  a  policy  may 
be  ruie-Based  and/or  identity-based.  Administratively-directed  access 
control  and  restriction  of  covert  channel  bandwidth  from  a  host  Into  a 
network  otter  good  examples  ot  filtering  functions  which  an  associated 
security  component  may  Impose  on  a  host.  These  types  ol  functions  are 
most  conveniently  provided  by  a  FE  module,  either  non-transparent  or 
transparent.  Integration  of  enforcement  functions  wilhin  the  host  at  which 
the  enforcement  Is  directed  imposes  severe  trust  requirements  on  the 
host's  architecture. 

TCB  Boundaries  and  Evaluation  Concerns 

This  criterion  measures  the  size  of  the  trusted  computing  base 
concerned  with  COMSEC-related  (unctions.  It  is  an  indication  of  the 
system-level  evaluation  task's  scope  and  difficulty,  in  the  transparent  FE 
approach,  COMSEC-related  TCB  functions  are  confined  to  the  outboard 
subsystem.  In  general,  the  complexity  ot  an  embedded  system  such  as  a 
cryptographic  FE  (either  transparent  or  non-transparent)  is  less  than  that 
o(  a  general-purpose  host  computer,  simplifying  evaluation,  but  should 
not  be  dismissed  as  Insignificant.  A  protocol-oriented  cryptographic 
component  may  easily  contain  thousands  or  tens  ot  thousands  of  lines  of 
code.  When  the  non-transparent  FE  approach  is  used,  most 
COMSEC-iolaied  TCB  functions  remain  in  the  outboard  subsystem. 
Depending  on  the  capabilities  built  Into  the  host-FF.  prolocol, 
employment  ol  such  a  protocol  may  or  may  not  imply  the  need  lor 
host-based  trusted  functions.  Integration  ot  COMSEC  within  a  peripheral 
places  a  larger  trust  burden  on  the  peripheral's  associated  host,  although 
appropriate  peripheral  design  stralegies  can  act  to  bound  this  concern. 

Transparency 

This  criterion  measures  the  extent  to  which  an  existing  host 
computer  (hardware  and/or  software)  must  be  modified  in  order  to 
coexist  wilh  COMSEC.  Success  in  this  area  allows  a  COMSEC 
integration  approach  to  be  applied  in  order  to  protect  existing  unmodilied 
hosts.  Clearly,  the  transparent  FE  approach  is  most  successful  In 
satisfying  this  criterion.  It  is  followed  by  ihe  non-transparent  FE 
approach,  typically  requiring  only  software  modification.  The  peripheral 
approacli,  typically  requiring  software  and  hardware  modifications,  is  least 
transparent. 

Costs 

The  incremental  costs  ot  adding  security  to  a  network  system  can 
be  evaluated  In  several  dimensions.  Unit  purchase  cost  (or  the  security 
components  is  the  most  obvious  parameter,  but  operational  support 
costs  olten  assume  dominant  Importance  over  a  system's  life  cycle. 
Another  dimension  of  cost  deals  with  the  security  components'  Impact  on 
overall  system  performance. 

The  peripheral  Integration  approach  offers  the  potential  for 
significant  advantages  with  regard  to  purchase  cost.  When  COMSEC  is 
integrated  within  a  host  computer's  hardware  base,  less  duplication  of 
hardware  components,  packaging,  and  software  is  required  in  order  to 
Incorporate  security.  Both  FE  approaches  Incorporate  their  own 
separately-packaged  autonomous  processors,  and  are  therefore  likely  to 
be  more  expensive  to  produce  than  a  peripheral  implementation  On  the 
other  hand,  an  FE  approach  can  be  applied  to  a  diverse  range  of  host 
computer  types,  which  may  allow  improved  economies  of  scale  for  FE 
approaches. 
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The  peripheral  approach  also  oilers  benefits  with  regard  to 
maintenance  and  operational  support.  When  COMSEC  is  provided  by  a 
computer  vendor,  the  vendor  can  maintain  the  COMSEC  components 
along  with  their  associated  host  computer.  This  integrated  support 
improves  overall  system  availability  by  reducing  "linger  pointing"  among 
multiple  vendors  of  different  network  system  components. 

Different  integration  alternatives  have  different  impacts  on  system 
performance.  The  peripheral  approach's  impact  is  direct:  processor 
cycles  used  for  COMSEC  component  control  are  not  available  to  perform 
other  tasks.  While  tangible,  this  burden  will  often  be  fairly  minor.  If 
applied  indiscriminately,  FE  approaches  can  perturb  the  operation  of 
communications  protocols  in  ways  which  can  impact  performance 
severely.  For  example,  introduction  ot  added  control  Information  into 
transmitted  messages  can  cause  packets  to  be  fragmented  Into  multiple 
packets,  increasing  overhead  and  communications  costs.  Careful  system 
engineering  is  required  in  order  to  avoid  such  inefliciencies. 

Enhanced  Host-COMSEC  Interaction 

This  criterion  considers  the  richness  of  a  COMSEC  component's 
service  interface,  in  terms  of  lhe  types  of  control  which  can  be  Invoked 
and  data  which  can  be  passed  across  that  Interface,  For  example, 
authentication  data  carried  in  a  peer-peer  protocol  between  COMSEC 
components  can  be  reflected  to  an  associated  host  and  used  by  the  host 
as  an  input  to  its  Internal  access  control  and  authentication  mechanisms. 
In  the  other  direction,  host-resident  data  can  be  provided  as  an  input  to 
access  authorization  decisions  made  within  a  COMSEC  component. 
These  examples  illustrate  the  composition  ol  COMSEC  and  COMPUSEC 
into  an  overall  INFOSEC  architecture.  The  peripheral  approach  allows  the 
most  powerful  service  Interface,  followed  by  the  non-transparent  FE. 
The  transparent  FE  presents  no  explicit  service  interface,  and  therefore 
is  least  attractive  with  regard  to  this  criterion. 


Conclusions 

Each  approach  has  good  and  bad  points  with  respect  to  different 
criteria.  This  reflects  the  fact  that  different  approaches  are  best  suited  to 
different  parts  ot  the  overall  COMSEC  market  space. 

The  peripheral  approach  Is  quite  flexible,  offers  a  powerful  service 
Interface,  and  can  be  applied  throughout  lhe  protocol  hierarchy.  The 
peripheral  approach  Is  poorly  suited,  however,  to  performing 
enlorcement  functions  to  restrict  Its  associated  host.  Because  ot  this 
characteristic,  Its  cost  and  functionality  benefits  will  probably  first  be  fully 
appreciated  by  customers  with  unclassified  processing  requirements. 
Until  highly  trusted  hosts  become  more  widespread,  II  appears  that 
FE-based  protection  will  be  required  for  many  classified  processing 
needs.  II  is  possible,  however,  lor  FE-based  approaches  at  lower 
protocol  layers  to  be  used  In  conjunction  wilh  hosl-based  COMSEC 
providing  fine  granularity  protection  at  higher  protocol  layers. 

The  FE  approaches  are  more  cosily,  less  flexible,  and  their  protocol 
layer  applicability  is  more  limited.  On  the  other  hand,  their  encapsulation 
of  functions  within  a  separate  security  perimeter  simplilies  system-level 
evaluation.  The  transparent  FE  offers  a  unique  benefit;  it  can  provide  a 
“security  overlay"  at  network  interlaces,  protecting  the  traffic  of  existing, 
unmodified  host  computers.  The  non-transparent  FE's  explicit  service 
interface  allows  it  to  provide  better  support  to  host-based  (unctions  than 
a  transparent  FE  can  provide. 


I  would  like  to  thank  the  anonymous  reviewer  ot  a  draft  version  of 
this  paper  tor  comments  which  suggested  useful  areas  towards  which  to 
focus  additional  discussion. 
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Abstract 

The  Secure  Data  Network  System  (SDNS)  project  has  devel¬ 
oped  a  security  architecture  within  the  Organization  of 
international  Standardization's  (ISO)  Open  System 
Interconnection  (OSI)  computer  network  model.  The 
foundation  of  the  SDNS  security  architecture  is  based  on  a 
distributed  key  management  technique  that  is  embodied  in  an 
application  layer  Key  Management  Protocol  (KMP).  In  the 
SDNS  architecture  the  KMP  provides  a  uniform  mechanism 
for  the  establishment  of  secure  communications.  This  paper 
describes  the  security  services  furnished  by  the  KMP  and 
examines  the  relationship  of  the  KMP  to  the  OSI  reference 
model. 
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Key  management  is  defined  by  ISO  as  "the  generation, 
distribution/issuance,  storage,  updating,  destruction,  and 
archiving  of  keys,"  The  SDNS  model  for  key  management 
distributes  this  functionality  into  every  security  device  in  a 
communication  system.  The  generation  or  distribution  of  a 
key  is  then  the  responsibility  of  each  pair  of  communicating 
security  devices.  Before  any  instance  of  secure 
communication  between  SDNS  systems  the  peer  devices 
must  use  the  Key  Management  Protocol  to  establish  their 
identities  and  then  determine  a  key  to  use  for  subsequent 
communications. 

Correct  identification  of  remote  systems  is  assured  by  mutual 
authentication.  The  authentication  of  SDNS  security  devices 
is  based  on  the  exchange  of  credentials.  The  credentials 
provide  identity  information  and  information  that  may  be 
used  for  access  control  decisions.  A  drivers  license  or  u 
credit  card  are  good  analogies  to  the  security  devices 
credentials.  The  credentials  are  issued  by  a  central  authority 
and  are  subsequently  used  without  any  interaction  with  the 
central  authority.  SDNS  will  provide  a  Key  Management 
Center  (KMC)  that  will  be  the  responsible  authority  for  the 
creation  and  distribution  of  credential  material. 

The  SDNS  Key  Management  Protocol  is  the  mechanism  for 
the  exchange  of  credentials.  The  basis  of  the  KMP  is  a 
simple  four-way  handshake.  Two  communicating  systems 
must  first  exchange  the  credentials  that  describe  themselves, 
Each  of  the  peer  systems  validates  the  credentials  and  then 
exchange  messages  that  determine  how  they  will 
communicate.  This  second  pair  of  messages  is  encrypted  by 
a  key  that  each  system  has  determined  from  the  exchanged 
credentials.  The  ability  of  each  peer  to  decrypt  the  second 
exchange  tests  the  correctness  of  the  key  that  was  selected  or 
formed  from  the  credential  exchange.  In  this  manner  the 
successful  validation  of  the  second  pair  of  messages 
completes  the  mutual  authentication  of  the  peer  devices. 

The  SDNS  project  has  defined  specific  cryptographic  algo¬ 
rithms  and  data  formats.  While  these  algorithms  ensure  the 
interoperability  of  government  certified  security  systems,  the 
definition  of  the  architectural  model  and  the  protocols  are 
independent  of  these  algorithms,  The  protocols  are  capable 
of  supporting  multiple  algorithms  and  define  only  the 
mechanisms  for  transferring  information  used  in  the  key 
management  operations. 


Application  Layer  Model 

Key  management  is  defined  within  the  SDNS  architecture  as 
an  application  service  element.  A  model  of  SDNS  key  man¬ 
agement  in  the  application  layer  of  the  OSI  reference  model 
is  illustrated  by  Figure  1.  In  this  model,  key  management  is 
divided  into  agents  that  support  the  user  and  a  Key 
Management  Application  Entity  (KMAE)  that  supplies  the 
communication  services.  The  communication  services 
consist  of  the  ISO  standard  Application  Control  Service 
Element  (ACSE)  and  the  SDNS  defined  Key  Management 
Application  Element  (KMAE).  In  this  model  the  Key 
Management  Protocol  (KMP)  provides  the  services  defined 
for  the  KMASE. 

The  Key  Management  User  Agent  (KMUA)  and  the  Key 
Management  Server  Agent  (KMSA)  are  the  local  and  remote 
entities  that  act  on  behalf  of  a  user  to  manage  the  TEKs  and 
credentials.  These  agents  provide  all  of  the  authentication 
and  access  control  services  based  on  information  provided  by 
the  KMAE.  The  KMUA  and  KMSA  are  also  responsible  for 
the  generation  of  TEKs  based  on  the  credentials.  The 
management  of  the  credentials  and  keys  is  indicated  by  the 
management  information  bases  (MIBs)  in  Figure  1.  The 
establishment  of  a  cryptographic  association  is  used  in  this 
model  to  indicate  the  existence  of  a  TEK  shared  between  the 
agents,  This  association  includes  attributes  that  describe  the 
intended  usage  of  the  TEK  and  access  control  limitations, 

It  is  important  to  note  that  ihe  duration  of  the  cryptographic 
association  is  normally  longer  than  the  duration  of  the  key 
management  association.  The  key  management  association 
and  the  lower  layer  protocols  are  used  to  establish  the  TEK 
and  it's  attributes.  After  a  cryptographic  association  is 
formed  the  key  management  and  application  associations 
may  be  released,  This  allows  the  use  of  the  TEK  to  be 
independent  of  the  instance  of  communication  used  to 
establish  the  TEK, 

The  KMP  requires  the  services  of  the  ISO  application  layer 
protocol  ACSE  and  the  presentation  protocol.  These 
protocols  provide  the  means  for  the  communication  of  key 
management  information.  SDNS  has  defined  requirements 
on  the  protocols  used  for  the  application,  presentation, 
session,  and  transport  layers  to  ensure  the  interoperability  of 
SDNS  key  management  implementations. 
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Communication  Protocol  Requirements 

The  communication  protocols  required  by  the  KMP  are  stan¬ 
dardized  for  the  application,  p.escntation,  session,  and  trans¬ 
port  layers  of  the  OSI  reference  modei,  OSI  conformant  pro¬ 
tocols  are  specified  by  SDNS  for  these  communication 
layers.  The  ACSE  protocol  is  required  in  the  application 
layer  for  SDNS  key  management.  ACSE  provides  services 
for  the  establishment  and  termination  of  application 
associations. 

A  minimal  Presentation  Protocol  is  required  by  SDNS  key 
management.  The  presentation  layer  functions  include  the 
negotiation  of  transfer  syntaxes  and  may  provide 
transformations  between  the  transfer  and  abstract  syntaxes. 
SDNS  key  management  uses  a  single  standard  transfer 
syntax. 

The  Session  Protocol  provides  services  for  the  organization 
and  synchronization  of  a  dialog  between  presentation  layer 
entities.  The  KMP  requires  only  the  kernel  and  duplex 
function  units  of  the  standard  Session  Protocol.  The  transport 
layer  provides  for  the  reliable  transfer  of  data.  Transport 
protocol  class  4  (TP4)  is  required  to  support  SDNS  key 
management,  Lower  classes  of  service  may  be  negotiated. 
For  example,  while  TP4  is  the  default  for  interoperability, 
TPO  may  be  used  in  reliable  network  environments. 

Dual  Stack  Model 

The  communication  architecture  of  SDNS  key  management 
allows  the  key  management  communication  services  to  be 
separate  from  the  user  communication  services.  This  separa¬ 
tion  of  the  upper  protocol  layers  is  shown  in  the  dual  stack 
model  of  Figure  2.  Each  stack  represents  the  profile  of  the 
communication  services  required  by  the  applications.  The 
upper  layers  of  this  model  are  logically  distinct.  The  lower 
layer  protocols  may  or  may  not  be  shared  by  key 
management  and  user  traffic. 


USER 

APPLICATIONS 

KMUA 

USER 

UPPER  LAYER 
PROTOCOLS 

IasceI  Ikmap.1 

PRESENTATION 

SESSION 

SP 

TP4 

SHARED  LOWER 

LAYER  PROTOCOLS 

Figure  2.  SDNS  Dual  Stack  Model 

This  model  illustrates  a  security  protocol  (SP)  in  the  path  of 
user  communications.  In  the  currently  defined  SDNS  frame¬ 
work  this  security  may  be  implemented  at  the  link  layer,  net¬ 
work  layer,  or  transport  layer.  When  the  security  protocol 
needs  a  traffic  key  for  its  security  services  it  makes  a  request 
to  the  KMUA.  This  request  typically  occurs  when  a  new  in¬ 
stance  of  communication  is  to  be  established  through  a 
remote  security  system.  The  KMUA  then  uses  the  KMP  to 
establish  a  cryptographic  association  with  the  remote  KMSA. 
After  all  authentication  and  access  control  rules  are  validated, 
the  KMP  releases  the  key  management  association  and  leaves 
the  cryptographic  association  in  place.  The  new 
cryptographic  association  includes  the  TEK,  access  control 
privileges,  and  the  security  protocol  that  will  use  the  TEK. 
The  KMUA  then  returns  this  information  to  the  security 
protocol  which  subsequently  uses  this  information  for  its 
security  services. 

The  dual  stack  model  allows  SDNS  key  management  to  be 
used  for  ISO  or  non-ISO  user  traffic.  It  also  allows  for  the 
support  of  security  at  intermediate  systems.  Intermediate 


system  security  may  be  provided  by  the  SDNS  security 
protocols  SP2  (link  layer)  or  SP3  (network  layer).  An 
example  of  the  key  management  architecture  for  an  SP3 
intermediate  system  security  device  is  shown  in  Figure  3.  In 
this  figure  the  communication  service  requirements  for  the 
KMP  are  identical  to  the  previous  illustration.  The  user 
upper  layer  protocols  are  removed  to  a  separate  host  end 
system.  Traffic  from  the  protected  host  is  carried  on 
subnetwork  one.  The  ISO  network  layer  model  defines  the 
roles  of  the  Subnetwork  Independent  Convergent  Protocol 
(SN1CP),  Subnetwork  Dependent  Convergence  Protocol 
(SNDCP),  and  the  Subnetwork  Access  Protocols. 
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Figure  3.  Intermediate  System  Key  Management  Model 

Key  management  is  provided  at  intermediate  systems  in  the 
same  manner  as  end  systems.  An  application  association  is 
formed  between  security  devices  whenever  a  new  instance  of 
secure  communication  is  required.  The  KMP  then  uses  this 
association  to  form  the  cryptographic  association.  The 
association  is  used  to  support  security  services  between  the 
intermediate  systems. 

KMP  Services 

The  KMP  provides  mechanisms  for  the  following  basic  ser¬ 
vices: 

•  Authentication  of  peer  devices. 

•  Access  control  based  on  authenticated  creden¬ 
tial  information. 

•  Traffic  key  establishment  and  maintenance 
with  other  security  devices. 

•  Rckey  with  the  KMS  to  obtain  new 
credentials. 

•  Establishment  and  maintenance  of  crypto¬ 
graphic  associations  with  other  security  de¬ 
vices. 

•  Distribution  of  Compromise  Key  Lists. 

The  above  services  are  used  together  for  three  basic  functions 
-  the  establishment  of  cryptographic  associations,  rekey  to 
obtain  new  credentials,  and  the  distribution  of  Compromise 
Key  Lists,  Each  of  these  basic  functions  always  provide 
capabilities  for  authentication  and  access  control. 

Cryptographic  Association 

A  principle  function  of  the  KMP  is  the  establishment  of 
cryptographic  associations  with  other  security  devices.  A 
cryptographic  association  consists  of  a  Traffic  Encryption 
Key  (TEK)  and  associated  attributes  that  determine  the  usage 
of  the  TEK.  The  TEK  established  by  the  KMP  may  be  used 
by  any  other  security  service  that  uses  cryptography.  SDNS 
has  currently  defined  protocols  that  provide  security  services 
at  the  Transport  and  Network  layers  of  the  OSI  reference 
model.  Extensions  are  planned  for  protocols  that  will  support 
Link  layer  security  SDNS  has  also  defined  security 
extensions  to  X.400  lur  electronic  mail  security.  The  SDNS 
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electronic  mail  does  not  require  a  cryptographic  association, 
but  may  use  the  KMP  for  the  rekey  of1  credentials. 

The  TEK  usage  is  determined  by  an  option  negotiation  per¬ 
formed  during  the  key  establishment.  The  categories  of  op¬ 
tions  include  algorithm  options,  labeling  requirements, 
keying  granularity,  security  protocols,  and  protocol  options. 
These  selections  can  be  placed  in  an  order  to  express  the 
preferences  of  the  initiating  device.  The  responding  device 
then  selects  an  appropriate  intersection  if  possible.  This 
negotiation  allows  SDNS  devices  to  support  several  security 
protocols  or  service  options.  Defaults  have  been  defined  to 
ensure  interoperability.  The  negotiation  enables  the  device  to 
interoperate  and  where  applicable  provide  additional  services 
beyond  the  defaults. 

Access  control  attributes  are  an  important  feature  of  the 
cryptographic  association.  The  cryptographic  association  is 
only  formed  if  mandatory  and  discretionary  access  control 
rules  based  on  the  credentials  pass  appropriate  checks. 
During  the  traffic  key  establishment  Peer  Access 
Authorization  (PAA)  is  enforced.  Within  the  SDNS  project 
the  specification  of  consistent  access  policies  and  access 
control  label  formats  have  been  defined  by  the  SDNS  Access 
Control  working  group. 

Maintenance  of  the  cryptographic  association  is  provided  for 
by  a  procedure  to  update  a  THK.  and  by  the  capability  to  as¬ 
sign  a  new  TEK  to  an  existing  cryptographic  association. 

Credential  Reke.v 

The  KMP  provides  support  for  the  electronic  distribution  of 
credential  material.  This  capability  to  rekey  credentials  is  in¬ 
tended  only  to  be  used  on  an  infrequent  basis.  The  rekey  of 
credentials  is  similar  to  the  periodic  issuance  of  new  credit 
cards  or  drivers  licenses.  The  rekey  provides  a  mechanism 
for  the  re-certification  of  a  device  by  the  Key  Management 
Center  (KMC).  The  rekey  in  effect  changes  the  expiration 
date  of  the  credentials.  It  is  not  intended  that  the  rekey  be 
used  to  change  the  identity  or  access  control  attributes 
contained  within  the  credentials. 

Valid  credentials  are  required  to  obtain  credential  material 
from  the  KMC.  To  enroll  a  device  into  the  SDNS  system 
manual  or  out  of  band  techniques  are  required  to  install  the 
first  set  of  credential  material.  After  an  SDNS  device  is 
enrolled  all  future  interactions  with  the  KMC  can  be 
performed  through  a  communication  network. 

In  addition  to  the  interactive  rekey,  the  KMP  supports  a 
staged  rekey  that  allows  credential  material  to  be  distributed 
to  security  devices  that  may  not  have  direct  connectivity  to 
the  KMC.  The  staged  rekey  uses  rekey  agents  that  act  as 
surrogate  KMCs.  The  ickcy  agents  accept  requests  from 
devices  for  new  credentials  and  store  the  request  for  later 
delivery  to  the  KMC.  Multiple  requests  may  then  Ik  grouped 
together  into  a  single  hatch  to  be  interactively  re  keyed  with 
the  KMC.  After  an  agent  obtains  the  new  credential  material 
from  the  KMC.  the  KMP  provides  services  for  the  delivery  of 
the  material  from  the  agent  to  the  security  device  that 
originally  requested  the  rekey.  Multiple  agents  are  allowed 
between  the  requesting  device  and  the  KMC.  The  KMP. 
however,  does  not  define  an  agent  to  agent  rekey  protocol.  It 
is  assumed  in  the  staged  rekey  model  that  any  mechanism 
that  meets  a  systems  security  policy  requirements  can  be  used 
to  move  the  rekey  between  agents.  This  allows  for  a  variety 
of  rekey  material  delivery  techniques  that  include  manual 
delivery  on  disks  or  data  keys,  or  the  use  of  electronic  mail. 

Compromise  Key  List 

The  KMP  provides  limited  slip-,*  rl  for  the  management  of 
access  control  information.  In  particular  the  KMP  can  be 


used  io  transfer  lists  of  credential  identifiers  that  are  no 
longer  valid.  This  Compromise  Key  List  (CKL)  can  be 
compared  to  lists  of  credit  card  numbers  at  retail  stores.  In  the 
same  manner  that  a  store  clerk  might  check  the  list  of  credit 
card  numbers  to  ensure  the  validity  of  a  monetary  transaction, 
an  SDNS  device  can  compare  a  credential  identifier  to  the 
CKL  to  ensure  the  validity  of  a  credential. 

To  guarantee  that  SDNS  security  devices  have  the  latest 
CKL,  CKL  version  numbers  are  exchanged  during  traffic  key 
establishment.  This  allows  devices  to  learn  the  latest  CKL 
version  number  from  their  peers.  To  obtain  a  new  CKL, 
devices  may  request  CKL  from  either  peer  devices  or  from 
the  KMC.  Since  the  KMC  is  the  ultimate  authority  for  the 
creation  and  distribution  of  CKL,  security  policy  may  require 
some  security  devices  within  a  community  to  poll  the  KMC 
for  the  latest  CKL.  CKL  is  also  delivered  with  credential 
material  during  a  rekey  operation. 

Summary 

The  KMP  provides  a  uniform  mechanism  for  the 
establishment  of  secure  communications  in  the  SDNS 
architecture.  The  KMP  establishes  a  cryptographic 
association  that  can  then  be  used  at  any  layer  of  the  reference 
model  to  provide  security  services.  Th  .  TEK  bound  to  the 
cryptographic  association  is  installed  out  after  the  identities 
of  peer  devices  arc  authenticated  and  acw".  control  cheeks 
based  on  the  authenticated  information  pass.  Option 
negotiation  performed  during  the  key  establishment  allows 
security  services  and  protocols  ut  any  layer  of  the  OSI 
reference  model  to  be  flexibly  supported.  The  option 
negotiation  includes  the  ability  to  bind  additional  access 
control  information  to  the  cryptographic  association.  Addi¬ 
tional  capabilities  are  provided  by  the  KMP  to  support  the 
maintenance  of  cryptographic  associations,  obtain  new  cre¬ 
dentials  from  the  Key  Management  Center,  and  obtain  the 
latest  Compromise  Key  List  from  a  peer  device  or  from  the 
KMC. 

The  key  management  architecture  is  supported  by 
communication  requirements  that  define  an  interoperable 
stack  of  protocols  for  use  by  the  KMP.  This  architecture 
supports  security  installed  in  end  systems  or  intermediate 
systems.  Although  the  protocols  specified  for  use  by  the 
KMP  are  ISO  conformant,  usei  traffic  docs  not  have  to  be 
carried  on  ISO  protocols. 
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ABSTRACT 

Tin*  ivplaceim-ni  of  hard-wired  crypto  processor*  by 
* >|i  w  arc-  :nul  lirmw  are-t-onl  nulled  processus  requires  techniques 
in  assure  tli.ii  < '( >Ms|-.C  mi|i wair  meets  its  security  r<*t]iii ic- 
Tiifiits  Inward  the  go;d  » 4’  gaming  this  assurance,  we  explore  the 
application  i»|  I'Minal  s|ieciiica(  imi  and  Vei  ilicatioii  technique*  in 
(  OMSK  l  ■  snftwurc  Till*  paper  (drill dies  ;i  Has*  of  (‘O.MSKO 
svsteiiis  and  :i  u.iiilitvinl  member  of  the  cl. is*.  A  Secure  Voire 
I  e|  limi;d  (A>\  1  )  1  he  ,-\SV  |  pi  ovules  a  research  vehicle  from 

uliuh  t"  *lud\  and  compare  vcnljcut ion  systems  lo  gain  insight 
mi<*  tin  i?  suitability  lor  verilviug  C 'OMSKC  soft  ware,  A  formal 
■  peciln  al r  <n  »*l  the  .\S\T  in  llnaie's  (  'iiiiimilliicaliiig  Sequent i;d 
I  *i  i  ■<  i-nm"  ((  SI'|  delii<>iiM  rate*  I  hi*  feasibility  ■  applying  f-Mhiul 
t“  hlMq'lr*  l«‘  a  class  i«|  (  '()\|sl  .(  *  *Vxtc|lts  'Pile  successful  .ippli- 
tailfU  n|  these  techniques  in  (  ,)\K|;c  .*,fiw;,,r  eali  increase 
a.v>-  Irani  *-  ( hat  I  lie  s,  *|i  w ill e  meet--  ll"  xcclll  |l  \  requirements 

1.  INTRODUCTION 

\>  ci  >in  put  ft  m  cMUif  li*  d'liiurale  ciiiniiiiiiiicai  loii  systems 
■'•id  pi»K-csN»m  the  reliability  «»l  software  and  haidw..*e  iliai  con* 
,l,,«  * ll«‘*ll  l>ec«»nie.H  cilleial  In  the  security  :uul  pel f« n  uiaiicc  of 
tlir^c  Mslciie.  riic  icplaei'iiii-nl  nf  lu  ,1-wii-d  crypto  pl*»ccxsors 

l*>  "nllWalr-  .<  Ini  . . •  •Illlnic'd  p|nct  s*.-  •(.*  leqllllc*  |er|i- 

Mli|iiev  in  a,sM}{«*  lhal  < ‘CAM  *.< '  x.,fiwa:«-  meets  j}.<  M'liinu 
re.puieiiirilU  *  i « *\\  iil  <(  die  g-  ll  nf  gaining  till'*  nsslll  ;|||IT,  \ve 
e\p|i»|e  the  *  |  >|>I|<*:1 1 1<  >||  i  *|  f  •  >|  tl|:i  I  spe<-||le;|l  |n||  ;|||<|  V  e|  |]jr:il|,ijj 
techniques  In  l  OMSKc '  snfi  uaie  This  pa  pel  identifies  a  «  ,.,xs  .,| 

<  C\N.(  systems  and  f*»i  m:ill/es  a  imniimal  member  of  the 
I  la.ss.  \  Viiiii-  \  n|(  e  Tel  Inilial  (  \"A  T)  The  language  selected 
•"I  *  I* h  I  lllidl/iltloli.  |  Inal'o's  (  ‘o|ill|il|l||calll1g  Sequent  |:i] 

IT"  isms  (CM»|  W ;i>  ehnsen  piunanly  Ini  ils  i  ap:ii  il \  in 

desildir  (111-  ,I.S\  Hr  lift  ‘Us  operation  of  scp.iinlc  p|«icessn|s 

"  1 1  lull  'll  -  (  '(  AN|  A  '  s\  s|.-||| 

I  !ic  \  r  t  liil  al  mil  \-vsexs||)elll  Stl|d\  (\  \S)  K  Conclude* 
lh.il  «S  Iinpli-  I  >i  fide  (Hr-  «!•»  li«»|  perform  adequately  as  lt«  in  hliiaihs 
u»  dcteiinnii*  i hr  "pi  *hty"  of  \ei dicahon  svsleins  The  V  \S 
d' linWcU't  p|n|llnte  t  hell'  H>e  li»  coillpale  and  r«  'll!  I  ...-.t  du>se 
Mso-m**  I  he  \S\  T  |i|n\  ide.s  a  I  |  eh  \e|||c|e  llnlll  \\  ll  It'll  l*» 
siiidv  and  >iu pare  veiilicaMnri  s\  leins  tn  jiam  msi^hi  n  tn  thrif 
’•>it  alulit  \  roi  vcjiO  <  |;,xs  ,,f  COMsKC '  S\>sien,s  .Seclmn’2 

"I  ■  lll>  pa  pel  ideni.V^  die  rkssnl  (  '<  )N|SK<  '  s\ si  e|||s  ml  ud  ami 
:t  class  III  pl<  ipert  les  In  In*  plnVcd  •  •(  l||«»r  *iyslei||s  Section 
uiloniiallv  de-»Tiiw>  |  hr  s.-,  uiiiy  pi»|iey  and  I'll ll<*(  l< iltsi lit  v  of  die 
\S\  I  In  seel  inns  l  ami  .*»  ..  subset  nf  1  Inure 's  (*S|f  is  pieseiited 
iiml  used  In  deiive  a  fur III  il  spenlicatlnll  nf  the  \S\  |’  I Tn.ill v . 
sc,  t|..||  li  SUII1I1I  111/cs  si  *11 1>*  IcxsuMs  learned  ||n|n  this  e  Ih  Ml  ill  id 
the  direction  |.»r  flllUle  Mnlk 

2.  A  CLASS  or  COMSEC  SYSTEMS 

I  he  cht.SK  n|  C  OMSKC  systems  t sf  interest  in  our  siud\  •ire 
llsrse  systems  lofupnsed  of  ll  set  .if  device*  co| inerted  iiy  poten¬ 
tially  unrclialde  media  dint  allow  users  st at  mm-d  at  dilfejent  <lev- 
ices  in  cninmuiiieaic  Km  li  device  allows  the  processing  of  mfor- 
hilt  doi-s  lint  allow  Us  pel  Uianeiit  storage  \n  storage  is 
poc.  ih  [  l»r\ .  Mid  (hiit  n|  teiiijxMary  tin  it  o  hulleis  The  C()MSl'(’ 

i  -I  i  *  « '\|s|  <  |>  S>flw,r-  OmI  -•..i.ln.F  ll,.-  .T\|l«^rv|  hi  »•.>. 

iiu  rrl.i»  •••.  Mill,  » I,-  ri  |-<>>Kr.i|.|,l.  hlat- i'll  Inn  ..r  i  iiii-l'in'iii..  .-f\  ;-ii  igr  ^pli  |.-  Imr. 


.system  has  n««  ctmlrol  over  the  integrity  or  privacy  of  data 
transinilled  on  the  communicalion  medium  between  devices. 
COMsKC  security  requires  securing  communication  between 
users  of  a  COMSl’X*  system  so  dial  only  those  individuals  stsi* 
tinned  at  a  device  properly  connected  to  the  system  may  enter 
information  to  <>f  cxlrucl  information  from  the  system,  The 
attackers  of  (.‘OMSKC  security  arc  those  individuals  who 
at  loin]  it  u>  a  Her  i  com  muiiical  ions  over  tlie  system  in  any  other 
way  Kuture  references  to  COMSK('  systems  rcfci  speeilieally  to 
the  class  of  systems  described  above. 

'Phe  threats  to  security  for  information  processing  systems 
fall  hi  three  categories:  unauthorized  disclosure  of  information, 
imaud’oiT/cd  mcKldication  of  information,  ami  denial  of  use  of 
system  ns, nines.  Conventional  computer  security  measures 
require  control  mi  die  How  of  iiilortnut ion  between  tlu  device 
and  the  user.  The  Orange  Kook  ]2)  recpiires  the  dcliniliou  of  u 
trusted  eo|  ipniing  base  and  a  security  policy  identih  mg  subjects, 
objects  and  a  set  «.f  rules  to  determine  whether  a  subject  can  be 
pei  muted  access  lo  ;i|i  object.  CO.MSKC*  system  security  inesm- 
iir«*s.  «'ti  the  other  hand,  reipiirc  control  on  the  How  of  iiifonna- 
hoii  between  devices  Any  utlncks  directed  at  the  potentially 
unreliable  ( i.iiiuumieali.tii  media  may  result  m  a  release  ol  mes¬ 
sage  contents  to  malicious  individuals  oi  miseommunicnlion 
bet Wi'i'ii  atithori/ed  communicanis. 

'l'lie  basic  solution  lc»  the  COMSlX*  security  problc.n  is  a 
pioiiaiuhstic  tine,  encryption.  I'hc  encrypt  ton  of  information 
(low mg  at  loss  a  communication  medium  allows  the  attacker  to 
uain  data,  bill  not  useful  information  Strategic  cipher  methods 
I'M'*1  prevent  die  attacker  IV* »m  being  able  to  deriplcr  d-*- 
infoi  malioii  ih(ei«-,-pied  in  a  reasonable  auiounl  of  time,  t  hi  fur- 
luiialelv.  ciit'i ypi n*n  almie  <ioes  not  solve  all  COMSIX*  probletiis 
Acenidiiig  to  Yictoi  \o>do«  k  10  major  goals  in  coimnunieni ion 
security  are  to  (ll  prevent  die  release  of  message  contents, 
prevent  message  trallii'  analysis,  detect  message-stream 
liKMlllicutinli.  detect  deiiud  of  message  service,  ;ili< I  detect  spuri¬ 
ous  assoeiai  i,  in  initiation  Achieving  these  goals  may  require  the 
use  of  miiipli,  aied  communication  pp  •t'Htds  between  users  of  the 
( ’( )NNl .( '  system 

itatiici  ihati  chose  a  <  •  mu  iiiuiiic.it  h  >u  protoixd  arbitral  dy  as 
die  basis  ot  out  investigation,  we  have  decided  to  Concept  rale  on 
a  class  of  pi  *  .pei  lies  .  a((ei|  |(»d  (Hack  separation  that  apply  to  a 
■.ond  mage  ..|  t’OMsKv’  systems  |{ed  Black  sepal  at  ion  pri¬ 
mal  dy  deaL  with  preventing  die  release  of  message  contents 
(‘OMSKC’  systems  ale  usually  partitioned  into  distinct  sets  of 
Ucd  Cmu  teMis  and  Black  functions  culled  the  Beil  processing  par- 
i c mi  itiitl  tit.  Black  processing  partition,  resp-ctivelv.  All  tnlonmt- 
i ion  that  is  plaintext  is  considered  to  be  Bed  data  and  ail  inlbr- 
uialioi  that  is  eiieryptecl  is  considered  to  be  Black  data.  It  is  I  lie 
respoinubility  of  the  <’()MSlv(’  boundary  to  mediate  all  informa¬ 
tion  How  between  the  Bed  a  ml  Black  processing  partitions  to 
ensure  that  no  Bed  data  is  conducted  into  the  Black  processing 
paiutioM  of  the  system  without  first  being  encrypted.  This  pro¬ 
perty  ts  referred  tons  Bed  Black  separation. 

3.  AN  EXAMPLE  OK  COMSEC  SOFTWARE 

The  example  chosen  its  the  basis  of  our  investigation  is  a 
simplification  of  an  existing  system,  the  Advanced  Narrowband 
Digital  \‘<>ice  Terminal  (ANDYT),  which  provides  secure  voice 
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and  (lain  processing  facilities  to  users.  [3j  Although  (lie  ANDVT 
i.s  t£x*  cniiiplex  to  investigate  with  each  verification  system  in  full 
detail,  its  basic  functionality  has  been  abstracted  into  an  example 
I  tint  can  be  studied  with  candidate  verification  systems  in  a  rea¬ 
sonable  amount  of  time.  This  example,  called  ASVT  for  A 
Secure  Voice  Terminal,  enforces  a  security  |xdicy  based  on 
lied.  I  Hack  separation. 

ASVT  Structure  and  Operation 

The  ASVT  is  split  into  three  major  blocks  of  operation  : 
the  Voice  Processing  Block,  the  Modem  Processing  Block,  and 
the  <‘OM$K(-  Module.  A  block  diagram  of  the  system  given  in 
Figure  it- 1  illustrates  the  four  external  interfaces  through  which 
voice  transmissions  may  Ilow,  Ue<l  Audio.  Bed  Digital,  Black 
Analog,  and  Black  Digital.  There  are  also  three  internal  inter¬ 
laces.  Voice  ('OMSlSC.  Voice  Modem,  and  Modem  C-OMSFC', 
for  voice  iiallic. 

The  ASVT  has  a  control  panel  which  allows  its  user  to  jn,r- 
Ibrm  various  operations  on  the  lenniiial.  The  control  pane) 
iiiihidt-  a  powr  switch,  n  Push  l*o  Talk  (PT'I')  button,  and  a 
riK  «ie  v.  i, ■(■tor  dial.  'Flic*  power  switch  allows  the  user  to  start  up 


aii<l  shutdown  Hie  ASVT.  T'lio  user  may  transmit  information 
by  depressing  PTT  or  receive  information  by  releasing  P'lvr. 
The  mode  selector  dial  allows  the  user  to  choose  between  the 
ciphertext  or  the  plaintext  mode  of  operation.  The  ASVT  also 
has  a  key  port  which  allows  the  user  to  install  new  k«*ys  for  the 
cncryptioii/decryption  of  infornmiion.  The  terminal  must  be 
clear  of  all  voice  transmissions  before  a  user  may  change  the 
status  of  the  control  panel  or  install  a  new  key. 

Five  applications  of  the  ASVT  are  possible  for  both 
transmission  and  reception  of  information.  The  application  in 
effect  nt  any  given  time  is  dependent  on  the  current  ASVT 
configuration.  The  current  configuration  is  defined  by  the  two 
external  interfaces  hooked  up,  and  the  positions  of  the  power 
switch,  the  PTT  button,  and  the  mode  selector  dial  on  the  con¬ 
trol  panel.  The  five  ASVT  applications  are  illustrated  in  Figure 
3-2.  The  Analog  User,  Digital  User,  Digital  Line  I,  and  Digital 
Line  2  applications  use  the  COMSCC  module  and  may  only  be 
used  while  in  ciphertext  mode.  There  is  nlso  one  Plaintext 
Application  which  allows  the  plaintext  transmission  and  recep¬ 
tion  of  information  by  the  ASVT  while  in  plaintext  mode.  Turn¬ 
ing  the  power  switch  on  brings  the  ASVT  up  in  the  Analog  User 
Application  and  ready  to  receive  data  -  that  is,  with  the 


J1  •  Red  Audio 
Intercoms, 
Telephone 
Sets 


J2  •  Red  Digital 
Digital  Data 
and  Signaling 
Devices 


J  3  •  Black  Analog 
Radios  or  Wireline 
Appliques 


■  14  -  Black  Digital 
External  Modems  or 
Digital  Networks 


Figure  3-1.  ASVT  Block  Structure 
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Figure  3-2.  ASVT  Applications 


130 


RED-AUDIO  and  BLACK-ANALOG  ex  ernal  interfaces 
hooked  up,  the  PTT  button  released,  and  h„-  mode  selector  dial 
set  in  the  ciphertext  position. 

During  transmission,  the  Voice  Processing  Block  performs 
fieri  voice  processing  functions  to  analyze  voice  transmissions, 
the  Modem  Processing  Block  performs  Black  modem  processing 
functions  to  code  important  bits  and  modulate  the  resulting  bit 
stream,  and  the  COMSEC  Module  Block  performs  the  encryp¬ 
tion  of  voice.  During  reception,  these  functions  arc  inverted. 
The  position  of  the  PTT  button  determines  the  direction  of  the 
(low  of  data  lor  the  ASV1  in  each  application.  In  the  ciphertext 
mode,  depressing  the  PTT  button  allows  Red  unencrypted  data 
to  enter  the  Voice  Processing  Block  from  either  the  Red  Audio 
or  lied  Digital  interface.  Releasing  the  PTT  button  allows  Black 
encrypted  data  to  enter  the  Modem  Processing  Block  from  either 
the  Black  Analog  or  Black  Digital  interface.  The  Plaintext  Appli¬ 
cation  does  not  perform  any  transformation  of  information  input. 
The  details  of  the  transformation  each  application  performs  on  a 
message  have  little  or  no  bearing  on  the  statement  of  the  secu¬ 
rity  policy,  For  ease  of  exposition  these  details  arc  omitted. 

Those  applications  that  use  the  COMSEC  module  require  a 
key  for  the  encryption  and  decryption  of  information.  Key3  may 
be  inserted  into  the  COMSEC  module  by  the  ASVT  operator 
through  the  key  port.  Users  at  two  different  ASVT  terminals 
may  comiminivale  through  applications  oilier  than  plaintext  only 
if  they  have  the  same  key  installed  All  key  management  and 
distribution  for  the  ASV'Ts  is  done  manually  by  ASVT  opera¬ 
tors;  no  keys  are  transmitted  automatically  between  ASVTs. 
The  ASVT  is  initially  configured  with  a  predefined  default  key. 

An  operator  wanting  to  transmit  data,  either  voiee  or  digi¬ 
tal,  on  the  ASVT  for  a  given  application  will  turn  the  |iower 
switch  on.  hook  up  the  interlace  channels  lor  that  application, 
select  the  ciphertext  or  plaintext,  inode  according  to  the  applica¬ 
tion.  depress  the  PTT  button  and  send  the  ASVT  data.  If  the 
operator  releases  PTT  during  transmission,  information  tnay 
then  be  received.  Likewise,  an  operator  wanting  to  receive  data, 
either  voice  or  digital,  on  the  ASVT  for  a  given  application  will 
turn  the  power  switch  on,  hook  up  the  interface  channels,  select 
the  ciphertext  or  plaintext  mode  according  to  the  application, 
and  release  the  PTT  button.  If  the  operator  depresses  PTT  dur¬ 
ing  reception,  information  may  then  he  transmitted,  ff  the  ter¬ 
minal  is  not  couligured  properly  lor  one  of  the  live  applications, 
information  may  he  neither  received  nor  transmitted. 

ASVT  Security  Policy 

The  security  policy  for  the  ASVT  is  bused  on  the  concept 
of  Red,  Black  separation.  It  in  split  into  two  policies,  an  external 
security  policy  and  an  internal  security  policy.  The  external 
security  policy  treats  the  ASVT  as  a  black  box  and  specifies 
Red  /Black  separation  on  its  input  and  output.  More  specifically, 
all  information  transmitted  by  the  ASVT  when  in  the  ciphertext 
mode  of  operation  must  be  Black,  encrypted,  data.  Thus,  the 
only  way  for  the  ASVT  to  transmit  Red,  unencrypted,  data  is 
when  the  mode  selector  dial  is  set  in  the  plaintext  mode. 

The  internal  security  policy  enforces  Red/Black  separation 
on  die  components  of  the  ASVT.  The  Voice  Processor  Block  is 
the  Red  processing  partition  and  the  Modem  Processor  Block  is 
the  Black  processing  partition.  During  transmission,  the  CoM- 
SEC  module  takes  Red  data  and  encrypts  it  creating  Black  data. 
During  reception,  the  COMSEC  module  takes  Black  data  and 
decrypts  it  creating  Red  data.  Furthermore,  the  only  way  data 
may  change  from  Red  to  Black  or  Black  to  Red  is  by  going 
through  the  COMSEC  module.  The  internal  policy  requires  that, 
when  in  the  ciphertext  mode,  all  information  transmitted  to  the 
modem  processor,  the  Black  partition,  must  be  Black,  encrypted, 
data  Thus,  the  only  way  for  Red  data  to  enter  the  Black  pro¬ 
cessing  partition  is  when  the  ASVT  is  in  the  plaintext  mode  of 
operation. 


4.  THE  CSP  LANGUAGE 

Process  isolation  reduces  t lie  amount  of  software  that  iiitc 
faces  with  critical  COMSEC  functions,  This,  in  turn,  reduces 
the  amount  of  software  within  the  COMSEC  boundary,  a  pri¬ 
mary  objective  of  the  assurance  task.  Piocess  isolation  may  be 
accomplished  through  physical  means,  by  separating  processes  on 
uistinct  processors,  or  through  logical  means  by  separating 
processes  using  proper  programming  techniques.  The  highest 
degree  of  COMSEC  assurance  is  gained  by  separating  processes 
on  distinct  processors.  Highly  reliable  COMSEC  software,  there¬ 
fore,  requires  the  asynchronous  operation  of  separate  processors 
within  the  COMSEC  system.  The  CSP  process  description  and 
specification  language  [G]  was  chosen  primarily  for  its  capacity  to 
describe  the  concurrent  operation  of  processes  and  properties 
about  them  in  a  formal  manner.  Although  a  thorough 
knowledge  of  CSP  is  not  necessary  to  understand  the 
specification  of  the  ASVT,  a  general  knowledge  is  helpful.  The 
rest  of  this  section  reviews  the  terminology  and  notation  that  is 
used  in  the  CSP  specification  of  the  ASVT. 

A  CSP  process  is  the  behavior  pattern  of  some  object. 
Each  process  has  an  alphabet  associated  with  it  defining  the  set 
of  events  relevant  to  its  description.  Processes  are  permitted  to 
communicate  through  those  channels  included  in  their  alphabet. 
The  notation  used  in  CSP  aids  in  the  description  of  a  process  ill 
terms  of  the  events  in  its  alphabet.  Unless  otherwise  specified, 
the  following  conventions  arc  used: 

1.  Symbols  in  upper  cose  italics  letters  denote  distinct 
processes,  e.g.  ASECURE-  VOICE-  TEH  MINA  l , 

MODEM-PROCESSOR.  SKIP. 

8.  Symbols  in  upper  ease  bold  denote  specifications,  e.g., 

C  M-R.ED-BL  ACK-S  EP  ARATIO  N , 
INCOMING-MK. 

3.  Symbols  in  upper  case  roman  denote  distinct  channels 
through  which  processes  may  communicate,  e.g., 
RED-AUDIO. 

•1.  Symbols  in  lower  case  roman  are  variables  denoting,  for 
example,  channels,  values  of  messages  sent  through  chan¬ 
nels,  function  names  mapping  values  to  new  values,  etc. 
The  symbol  s,  however,  is  reserved  to  denote  arbitrary 
sequences  of  events  in  which  a  process  may  engage,  called 
traces. 

5.  Symbols  in  lower  case  italics  denote  event  names,  e.g., 
pU-off. 

S.  The  alphabet  of  a  process  P  is  denoted  o P. 

Processes  may  communicate  through  channels.  "CHAN- 
NELl  ?  in"  denotes  the  event  in  which  value  n.  is  input  on 
CHANNEL1  and  "CHANNEL1  I  in"  denotes  the  event  in  which 
value  m  is  output  on  CHANNEL1.  The  choice  operator  "  I  " 
allows  the  behavior  of  a  process  to  be  influenced  by  outside 
events.  If  P  and  Q  arc  processes  and  el  and  eS  are  events,  the 
process  (el  — *  P  I  eS  —*  Q)  behaves  like  process  P  if  el  is  the 

fvent  to  nrnir  and  behaves  | j k . ocess  Q  if  e?  is  the  fi 

event  to  occur.  The  process  P  <1  b  l>  Q  is  defined  as  P  if  b 
else  Q.  This  definition  is  generalized  to  allow  any  arbitrary  nest¬ 
ing  with  binding  from  left  to  right  if  not  otherwise  specified  by 
parentheses.  Thus,  Pi  <1  bl  1>  PS  <1  b2  1>  PS  is  defined  as 
the  process  if  bl  then  Pi  else  if  b2  then  PS  else  PS. 

A  trace  of  a  process  is  a  finite  sequence  or  events  in  which  a 
process  has  engaged  at  some  moment  in  time.  A  trace  may  be 
denoted  by  the  letter  s  or  a  sequence  of  events  enclosed  in  angle 
brackets,  e.g.,  <eventl,  events,  even tS>.  The  first  event  of  a 
trace  s  is  denoted  by  Sg  and  the  result  of  removing  the  first  sym¬ 
bol  is  s’,  e.g.,  <a,t>,c>0  =  a  and  <a,ii,e>’  —  <b,c>. 

P,Q  signifies  a  process  that  acts  like  the  successful  termina¬ 
tion  of  P  followed  by  Q.  If  P  does  not  terminate  successfully  then 
Q  does  not  start.  The  trace  of  this  process  is  s;t  where  s  is  the 
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i.cui'  of  /’  an  is  the  trace  of  Q  \  process  successfully  tcr- 
fu  ii ;it(*s  if  ;i in*  only  ir  the  priH-ess  ends  with  Sh’Il *,  A  process 
unsuccessfully  Leimiuutos  if  find  only  if  ihe  process  ends  with 
STOP. 

Processes  may  be  delined  to  run  concurrently  through  the  " 
(I  ”  operator,  e.g.,  P^Q  is  n  process  that  runs  process  P  in  paral¬ 
lel  with  process  Q.  Such  concurrent  processes  require  simultane¬ 
ous  participation  of  those  events  that  occur  in  both  oP  and  aQ. 
Events  occurring  in  P's  alphabet  but  not.  Q\  may  be  engaged  in 
by  /■*  independently  of  Q.  This  generalizes  to  the  situation  in 
which  many  processes  run  in  parallel  in  the  obvious  way.  A 
communication  can  occur  between  two  processes  running  in 
parallel  if  aud  only  if  both  processes  have  that  communication 
event  in  their  alphabets  and  both  processes  simultaneously 
engage  in  that  event,  i.e..  whenever  one  process  outputs  a  value 
onto  the  channel,  the  other  process  simultaneously  inputs  the 
same  value  from  l he  channel.  Thus, 

(Oil  !  V  -v  l‘)  II  (Cl  I  ?  m  —  «»>))  =  Cl  I  .  v  —(/'II  (*<)) 

If  only  otic  process  in  a  concurrent  combination  of  processes  has 
the  communication  event  in  its  alphabet,  then  that  proems  may 
engage  in  the  communication  event  independently  of  the  other 
[.‘ocesses. 

The  above  not  a  Lon  is  used  Tor  the  procedural  description  of 
the  be  tavior  of  pnv*  sses.  A  specific  at  ion  of  a  process  or  .system 
is  a  piedicate  <1csi,»‘  p‘»oii  of  the  way  it  is  intended  to  behave. 
The  spvdlicniioi.  of  pu,n\sscs  uses  the  six  conventions  listed  pre¬ 
viously  and  n  notation  that  is  srlf-ex plana t or v.  Notnfuni  that 
may  be  used  m  the  ASVT  specification  and  procedural  descrip- 
fi.'»  Kiiniiiiiiri/ed  ill  Table  I- 1  for  easy  reference. 
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Cm 

n  eiuimntnir.it  ion  event  of  m  on  C 

I./' 
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a  —  /' 

event  il  then  pUxess  P 

(n  -+l’l  k  -*Q) 

rt  then  /‘e| ioiee  b  then  Q 

V  ■  1  b  1..  Q 

P  if  b.  else  Q 

l’:Q 

P  successfully  followed  bv  Q 

/’II  q 

/*  ill  parallel  with  Q 

SKIP 

a  process  that,  does  nothing 

but  terminate  successfully 

Tabic  4-1.  CSP  Language  Subset  Summary 

5.  CSP  SPECIFICATION  OF  THE  ASVT 

ASVT  security  requires  enforcing  both  the  external  security 
Me*v  and  the  internal  security  policy  This  section  focuses  on 
(he  CSP  specification  of  the  internal  security  >f  the  system  us 
■Insfribed  in  section  T  I  h**  compiete  f’M*  spec itieai ion  is 
presented  m  |9j. 


This  .section  specifies  an  abstract  model  of  security  for 
secure  voice  terminals  containing  three  components  -  a  voice  pro¬ 
cessor,  a  modem  processor.  and  a  COM  SIT*  module.  An 
interpretation  instantiates  the  abstract  model  to  an  ASVT* 
specific  model.  A  functional  specification  of  the  ASVT  describes 
the  operation  of  the  ASVT.  Finally,  an  informal  argument  is 
given  that  the  COMS1.CO  module  conforms  to  the  security  policy. 
In  the  following  exposition,  values  of  functions  may  be  written  as 
sets  of  ordered  pairs,  e.g.,  'f  f  is  a  function  then  (»,b)  £  f  if  and 
only  if  f(n)  =  b.  Specific  fields  or  an  n- t  uple  may  be  specified  by 
the  n- tuple  name  followed  by  a  period  followed  by  u  field  name 
for  that  ii-tuple,  e.g.,  if  c  =  (fl.  12,  I’d,  I'd),  the  f*l  field  of  c  is 
specified  M.  'ruble  d-1  sum mnrizos  oilier  notation  used  in  the 
specilieu!  ion. 

Internal  Abstract  Security  Model 

The  ASVT  internal  security  policy  requires  that  the  only 
way  for  I  ted  (lata  to  enter  the  Modem  Processor  Mock,  the 
Mack  processing  partition,  is  when  the  system  is  in  the  plaintext 
mode  of  operation.  Our  goal  is  to  state  an  abstract  model  of  this 
policy  in  CSI\  Toward  this  goal,  let  VOICbUWQGESSOft, 
CGMSKC-MOPUUC,  and  MOD FA UyUO CICSSG P  be  the  CSP 
processes  of  the  voice  tenuiiml’s  voice  processor  compoueiil, 
COMSICC  module  component,  and  modem  processor  component, 
respectively.  YVe  assume  the  existence  of  the  following  constant 
sets,  functions,  and  channels  : 

M  is  a  set  of  messages. 

MS  is  a  set  ol  operating  modes  such  that  plaintext  £  MS. 

K  is  a  set  of  keys  Let  initial-key  £  Iv  be  the  default  initial 
key. 

KCII  is  the  com  mil  ideation  channel  over  which  the  keys  used  for 
encryption  and  decryption  are  passed. 

VCM1S/CCIIS/MC‘1|S 

are  sets  of  eomimmicntion  channels  over  which 
messages  pass  for  the  voice  processor/COMSKC’ 
modulc/modem  processor. 

CIK-  is  a  function  from  VC’ilS  (jMCIIS  [J  C -C T I S  to  bed, black} 
which  describes  t lie  type  of  messages  that  may  be  transmit¬ 
ted  over  Cl  I  when  not  in  plaintext  mode,  e.g.,  only  Mark 
data  may  be  transmitted  over  channel  Cl  I  if  ClIC(Cll)  ~ 
black. 

VC’S/C’C -S/Mcs  are  sets  of  -l-luples  dr  eribing  the  possible 
configurations  for  each  component.  For  in-chan, 
*  hi  t  — «-|,  a  ki  €  VVIIS/UIHS/MCIIS,  iiKxle  £  MJS. 

pti.sli-to_t.nlk  £  (true, false), 

(ui..dian,  on  i-cliaii.  mode,  push-to-talk)  signifies 
that  for  a  particular  value  of  push-lo-lalk,  nio.v 
sages  may  come  in  through  iiulmu,  go  out 
through  out -chan.  and  may  bypass 
encrypt  ion /decrypt  ion  if  mode  plaintext. 

VTS/MTS  aic  sets  of  functions  from  M  to  M  describing  the  set  of 
voice  processor/ modem  processor  message  (runs  ton  nations. 
!**<>**  ?dl  T  £  V'PS  u  MTS.  hi  M,  T(m)  is  the  message 
out  put  when  the  message  in  is  input. 

CTS  is  n  set  of  functions  from  M  x  K  to  M  describing  the  sei  of 
C'OMSEC'  module  transformations.  For  all  T  £  CTS,  (m,k) 
£  M  x  l\,  T((m,k))  £  M  is  the  message  output  by  the 
transform  a  lion  when  the  message  in  is  input  with  key  k 
installed. 

VCT/OCT/MCT  are  functions  from  VCS  (o  VTS/CCS  to 
CTS/MCN  to  M'FS  describing  the  transforma¬ 
tion  each  component  configuration  performs 
on  messages  input  'Finis,  for  all  c  £ 
VC’S/CC ’S/MCS  c  performs  transformation 
VCT(c)/CCT(c)/MCT(c)  on  messages  input. 
C’DP  is  a  function  from  VTS  CTS  |^J  MTS  to  (cipher,  deci¬ 
pher,  plain}  returning  the  type  of  transformation  per¬ 
formed.  Thus,  for  all  T  £  VTS  (J  CTS  y  MTS,  T  per¬ 
forms  an  encryption  if  C1)1*(T)  is  cipher,  performs  a 
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decryption  if  CDP(T)  is  decipher,  and  performs  no  encryp¬ 
tion  or  decryption  if  C1)P(T)  is  plain. 

Since  the  abstract  voice  tormina!  and  its  components  can 
not,  in  general,  decide  whether  data  received  i-s  Red  or  Black,  we 
must  rely  on  the  red  or  black  mark  given  to  each  channel  by  the 
Cl  1C  function.  The  security  model  must  ensure  that  only 
encrypted  data  Hows  through  channels  marked  black  and  that 
only  unceryptcd  data  Hows  through  channels  marked  red. 
Besides  internal  communieation  among  the  three  processes,  the 
voice  terminal  can  communicate  with  its  external  enviioiinioni 
through  an  external  interface.  Since  we  have  no  control  on  the 
external  environment,  we  assume  that,  through  the  external 
interface,  channels  marked  red  receive  only  Red  data  and  chan¬ 
nels  marked  black  receive  only  Black  data  .  It  is  the  job  of  tin* 
security  policy  model  to  describe  the  necessary  data  How  restric¬ 
tions  internal  to  voice  terminal  given  this  assumption. 

Given  the  above  structure  for  our  abstract  voice  terminal,  a 
number  of  requirements  for  Red/ Black  separation  exist.  Assume 
that  the  terminal  is  not  in  plaintext  mode  and  tl  it 
WICKJ'ltOCliSSOlt  and  MODEMJ'h'OC  ESSOI!  have  no 
way  of  encrypting  or  decrypting  data.  Red/ Black  separation 
requires  that  MODEM— l*!U)CESSOl!  input  and  output  data 
only  through  channels  marked  black.  Although 
VOICE- MtQCliSSOR  may  receive  Red  data  through  its  exter¬ 
nal  interface,  the  security  model  must  ensure  that 
( ’Ot\ ISE(  w\ tOl) \  7, E  encrypt  all  data  transmitted  from 
VOICE J’h'Oi  'ESSO!!  In'  \  I  ODES  U  'HOC ESSOI!.  Since 
( ’OMSEC-MODCLE  requires  Red  data  for  encryption. 
1  ()!<  ‘EJ '!!<)( 'ESSOi!  may  input  and  output  data  only  through 
channels  marked  red.  But  MODEM— 1*1! OCESSOJ!  may  only 
output  through  channels  marked  black.  COAISEC-MODULE 
must.  therefore,  decrypt  ail  data  transmitted  from 
MOUESU'IfOC  'ESSO!!  to  VOICEJWX  ESSOH.  finally . 
('OMSEC—MODVLE  must  neither  encrypt  nor  decrypt  data 
coming  from  and  going  to  tin*  same  processor.  Although  the 
ASVT  components  may  perform  a  transformation  of  messages 
received,  they  must  not  be  able  to  construct  new  messages. 

A  trace  of  a  voice  terminal  component  includes  all  the  com¬ 
munication  events  specifying  I  lie  messages  that-  have  been  pro¬ 
cess'd  by  that  component  The  speeilicni  ion  functions 
INCOMING-MSGS  and  OUTGOING_MSCS  return,  for 
ti  e"  s.  the  set  t if  messages  in|>u»  and.  respectively,  output  t«* 
cli .hi n el  chan. 

INCOMINCi-MSGS  (s.  tlmii)  - 
if*. «.  - 

then  {} 

else  if  s,,  »  (chan  ?  in) 

then  {lid  (J  INCOMING  .MSGS(.sVhan) 

•*Im'  1NCOMING-MSGSK .cIihii) 


OUTGOING _MSGS  [s,  rhau) 
it’s  =*  ■  • 

then  {} 

else  if  s,,  «  (chan  !  in) 

then  {in}  (J  OUTGOING-MSGS(sVimn) 
else  OUTGOING-MSGS(.s’.elmn) 

The  specification  for  V()l('E-J*!!OCESS()H, 
VP_RED_BLACK_SEPARATION.  states  that  all  messages 
that  exit  the  voice  processor  when  not  in  plaintext  mode  must  be 
a  proper  plain  transformation  of  a  message  that  entered  the  com¬ 
ponent  through  a  channel  marked  red  and  must  exit  the  com¬ 
ponent  through  a  channel  marked  red.  in  addition,  all  messages 
must  enter  the  component  only  through  channels  marked  red. 


VP _RED_BLACK_SEP ARATION  -  = 

all  c. 

(c  €  VOS 

A*  not  (c.modc  »  plaintext) 

((all  ou ^message. 

ouuim-ssagc  £  OUTGOING  JMSGS(tr.c.ouL-clian)) 

— ► 

some  in.-iucKNagc,  t. 

(l  €  VTS 

a  vcrr(c)  =  t 

A  in-message  £  INCOMING_MSGS(U’,c.in_chiin) 

A  t  (in_in  evingr)  =»  oul-iuc.isagr 
.V  CM>P(t)  -  plain 
A  Cl lC(e .out-chan)  «  red) 
tV.  (all  in_iiit\SMige. 

in-message  £  INCOMING-MSGS(tr,c. in-chan) 
ClK’(i'.iii_chiui)  =  red)) 

The  specific  a  I  ion  for  MODEM-l*UO( -ESSOI! , 

MP-RED._BLAGK_SEPAJLA.TION.  states  that  all  messages 

thill  exit  the  modem  processor  when  tint  ill  plaintext  mode  must 
be  a  proper  plain  transformation  of  a  message  which  entered  the 
component  and  must  exit  through  a  channel  marked  black.  In 
addition,  all  messages  must  enter  t  he  component  only  lit  rough 
channels  marked  black. 

MODEM J'lUK  ‘ESSOI!  sat  MP-RED.-BLACK-SEPARATION 
MP-KED-BLACK-SEPARATION  » 

all  c. 

KMCS 

A  not  (c. ninth*  “  plaintext) 

((all  oiit-iiicxs-tgc. 

out -message  £  OUTGOING-MSGSItiv.out-i  him) 

miiiu*  t,  iiumesNige. 

(t  £  MTS 

«v  M("r(c) - t 

A  in_nicfssagc  £  INCOMINC_MSGS((i1c.iiuclinii) 

A  t(  in- message)  =»  out -message 
A  Cl)B(t)*  plain 
A  C’llCJc.oul-cImn)  =5  black)) 

A*  (all  ill-message. 

iii-mehsuge  £  lNCOMlNG_MSGS(tr,c.iii_climi) 

C'l  1C '(c.iii— rhau)  »  black)) 


The  Specification  for  C'OMSEC-MODVLE, 
CM-ItED-JiLACK-iSEP  AHATION .  states  that  all  messages 
that  exit  the  module  when  not  in  plaintext  mode  must  be 
equivalent  to  the  proper  transformation  of  a  message  that 
entered  the  terminal.  Furthermore,  if  the  message  filtered 
through  a  channel  marked  red  and  exited  through  a  ehanii"! 
marked  black,  the  transform  a  l  ion  must,  perform  an  encryption  of 
the  message.  If  t  he  message  entered  l  It  rough  a  channel  marked 
black  and  exited  through  a  channel  marked  red,  the  transforma¬ 
tion  must  perform  a  decryption  of  the  message.  Finally,  if  the 
input  and  output  channels  are  marked  the  same,  the  transforma¬ 
tion  must  perform  neither  an  encryption  nor  a  decryption  of  the 
message.  The  specification  functions  INCOMING_MK  and 
OUTGOING—MK  specify,  for  trace  s.  the  set.  of  messages 
input  and,  respectively,  output  through  channel  chan  and  the  key 
that  wax  installed  when  each  message  was  input  or  output. 


VO! CEJyR  OCES S O! i  suit  VP_RED_BLACK_SEPARATION 


133 


INC0M1NG-MK  (s,  chan,  key)  - 
if  s  »  <  > 
then  {} 

else  if  s„  -  (KCH  t  k) 

then  INCOMING_MK(s\  chan,  k) 
else  if  s0  -  (chan  ?  m) 

then  {(m,key)|  (J  INCOMING_MK(s’, chan, key) 
else  INCOMIN  GJ4K(s’, chan, key) 


OUTGOING-MK  (s,  chan,  key)  = 
if  s  «  <> 
then  (} 

else  if  Si,  -  (KCH  ?  k) 

'ten  OUTGOING_MK(s’,  chan,  k) 
else  if  S(|  -  (chan  !  in) 

then  ((m,key)|  (J  OUTGOING JklK(s',chan,kcy) 
else  OUTGOING_MK(s’,chan,key) 


COMSEC-MODULE  sat  CM_RED_BLACK_SEPARATION 

CMJR.EDJ3LACK-SEPARATION  = 
ail  o,  out-message.  key. 

(c  e  ccs 

,t  not  e.motle  «  plaintext 

1*  (out-message. key)  €  OUTGOlNG-MKttr.c.out-chiui.iniliaLkuy)) 

some  l.  ill-message . 

(l  £  rl'S 
.6  CCT(e)  -  t 

,v  t((iu_inessage,key))  m  out— message 

,V-  (in-niewage.key)  6  INCOMIN G_MK(tr,c.in-chaii, initial-key) 

,?•  j(CH('(e. in-chan)  *■  red 
St  CIIC  [e  out-ehnu)  ”  black) 

— *  CPPR)  =  cipher) 

,V  ((Cllt '(c.ili-ehan)  »•  black 
A-  (‘lift  {e.oui.-tlian)  »  red) 

— s  Cl)l’(t)  =■  decipher) 

A-  (Cl!tt(e.in_elmn)  *  C -IK*  (e.oul-chan) 

— *  CDI’(t)  -  plain) 


A  voice  lennimil  that  is  described  as  it  coneiirrent  eottibina- 
t  n  >11  of  VOICEJ'ROCESSOR,  MOUEM-J'ROCESSOH,  uml 
( V >MsE(  A / ODULE  ami  is  an  interpretation  of  the  model 
described  in  this  section  guarantees  confortmuice  with  the 
Red'iihick  separation  property. 

In Uirnal  Abstract  Model  Interpretation 

An  ASVT  inter prelalion  of  the  id  struct  model  defined 
. ,ee  retptires  fhdiniint  the  opertiliolls.  sets  jind  fnnctioiis-  of  tl.* 
tttotle)  in  terms  uppropriate  to  the  the  ASVT  application  as 
described  in  section  3.  The  operations  appropriate  to  the  process 
describing  the  ASVT,  A-SECVRE-VOICE-TERMINAL,  and 
each  of  its  components  are  defined  by  each  process’s  alphabet. 

G/iSECURE-  VOICE -  TERM  INAL 
«  {hooL.upM  M,  selecLmodem,  ptL.an,  piLoff,  geLke y, 
got-key,  power-on,  power-off,  KCH.k,  RED-AUDIO, m, 
RED-DIGITAL. m,  VOICE-MODEM.m,  VOICE-COMSEC.m, 
MODEM-COMSEC. m,  BLACK-ANALOG. m, 
BLACK-DIGITAL.m} 

a  VOICE-PROCESSOR 

-  {hook-up^h]M,  sclecLtnodem,  plLon,  ptLoff,  get-keg, 

got—key,  power-off,  RED-AUDIO. m,  RED_DIGITAL.ni, 
VOICE-MODEM.m,  VOICE-COMSEC.in} 

a  COM SE C-MOD  VLB 

-  {Aooit_uptUiJh2,  se!ecLniodem,  ptLon,  piLoff,  get-key, 
got-key,  power-off,  KCH.k,  VOICE-COMSEC.m, 
MODEM-COMSEC.m} 


aMODEM-PROCESSOR 

—  {hook~upshicM,  sclccLmodcm,  ptLon,  ptt-off,  get-key, 
got-key,  power-off,  BLACK-ANALOG. m, 
BLACK-DIGITAL.m,  VOICE-MODEM.m, 
MODEM-COMSEC.m} 

where 

hook-up^  [h2  connects  channel  chi  6  {RED-AUDIO, 
RED-DIGITAL}  to  channel  ch2  G 
{BLACK-ANALOG,  BLACK-DIGITAL}  for 
input  and  output,  provided  that  such  a  connec¬ 
tion  results  in  a  proper  configuration  for  some 
application  of  the  voice  terminal.  Otherwise  it 
has  no  affect. 

selecLmodem  configures  the  system  to  operate  in  mode  in  £ 
MS  so  that  only  if  m  »•  plaintext  does  the  system 
bypass  the  cncryption/dccryption  of  messages. 
ptt-on  configures  the  system  so  that  messages  may  be 
transmitted  by  the  user. 

ptt-off  configures  the  system  so  that  messages  may  be  received 
by  the  user. 

get-key  notifies  the  system  that  a  new  key  is  about  to  be 
installed. 

got-key  notifies  the  system  that  a  new  key  hits  been  installed. 
pouier-on  powers  up  the  system. 
power-off  shuts  down  the  system. 

KCH.k  is  a  communication  event  of  key  k  over  channel  KCI1. 
RED_AUDIO.m,  RED-DIGITAL. m,  IJLACK-ANALOG.m, 
BLACK-DIGITAL.m,  VOICE-MODEM, in,  VOICE-COMSEC.m, 
MODEM-COMSEC.m  are  communication  events  of  message  m 
over  the  associated  channel. 

The  sets  and  functions  defined  in  the  abstract  model  are  relinei 
in  Figure  5-1. 

Functional  Specification 

ASECURE— VOICE-TERMINAL  is  described  as  three 
internal  communicating  processes  that  execute  concurrently  - 
VOICEJ'ROCESSOR.  COMSEC MODULE,  and 
A I OOEM-I  ‘ROCI'.SSOR  The  iiiilui!  configuration  of  the  system 
is  the  Analog  User  Application  with  the  I’TT  billion  released. 
Thus  the  ASVT  is  set  in  ciphertext  inode  and  is  ready  to  receive 
information.  This  requires  the  initial  voice  processor 
configuration  to  be  vp-reccivc-audio.  the  initial  COMSEC 
module  configuration  to  be  cm-reecivc,  and  the  initial  modem 
processor  configuration  to  be  mp_reecive_atmlog.  Once  the  sys¬ 
tem  receives  the  power-on  signal,  these  processes  start  executing 
in  parallel.  This  concurrent  activity  censes  when  power-off  is 
signaled.  The  system  then  shuts  down  and  waits  lor  the 
pouter-on  event  to  occur. 

A-SECt  HIE -  VOICE-  TERt\  UNA  I.  = 
power— on  —* 

0 

.Initial— kejr 
itllv«_afiilag)' 


The  component  functional  specification,  given  in  Figure  5-2, 
provides  a  CSP  operational  description  of  each  component.  The 
occurrence  of  each  event  of  the  component’s  alphabet  causes 
some  action  to  occur  within  the  component,  whether  it  be  the 
processing  of  a  message,  the  modification  of  its  current 
configuration,  or  synchronization  with  the  other  components  of 
the  terminal.  The  effect  each  event  has  on  the  system  as  a  whole 
is  as  specified  previously  This  forma)  description  of  ASVT  func¬ 
tionality  corresponds  to  the  informal  description  of  its  behavior 
presented  in  section  3.  Key  to  understanding  this  functional 
specification  is  the  fact  that  processes  executing  in  parallel 


(VOICE-PROCESSOR  ^^ 
COMSECMODVlEm^,u, 
II  MODEM-PROCESSOR 
A-SECURE-V01CE-TERMINAL 


134 


MS  { ciphertext,  plaintext} 

CHC  *  |(RKI)_Al'DI().r«l).  (KICD-J>IC!lTAI..w(l).  {BLACK_aNAI/X.\ black),  (BLACKJ)ICilTAL.  black), 
(VOIOKJUODl-lM.  black).  (VOICK-COMSEC,  rod),  (MOiWM_COMSl-X\  black} 

veils  «  {MOD-AUDIO.  Rl'in-DKilTAb.  VOICE-MOUFM.  VOICM-COMSKC } 

VOS  =  {vp-imnsiiiitjnidio  (*  -  (|{Kn^\UI)IOtVOICI-LCOMSPX:(fi|>>ier(eKi,trtic)  *), 

vp_l  ransmi(-_(iigiial  (*  -  (RIODJilCilTAl/.VOICK-C/OMSI'XJ.ciplirrtext  .true)  •), 

vp-traiistnit-plainlext  (*  "  (MODjNUDlO.VOKJhLMODKM, plaintext, true)  *), 
vpjrroivoj\udio  (*  «■  (VOlC'Iv-COMSKC.RFOD-Al,I)lOIciplit*rtoxt,l'»lso)  *), 

vj»joc.:ive_diKitnl  (*  -  (VOICK-COMSKC.RKD-DICilTAb.ciijhoitoxt.falsL*)  *), 

vp^.roooivo-plaintoxi-  (*  -  {VOieivAlODI^UUCD^UUMO.pImntoxt.falsc)  *)} 

VTS  *■»  |r«y nt lionize,  analyze,  null} 

V'CT  s  {( v p_t nmsmit^aud i<>,  analyze).  (vp-lrnnsmit-digital,  null), 

(vp.JiansiiiitwpliUtiU'Xt,  mill),  (vp-riM-civv-midio,  synthesize), 

(vp-m-eive-digital,  null),  { vp-rcmvo_4>ini  n i ext,  null)} 

eons  =  {liKD-AUDIO,  KKDJ)KilTAI„  VOICI'LOOMSKO,  MODICM-CJOMSKC} 

CCS  ss  {ciii-triitisiuit  (*  «  (VOKd’iX’OMSI'X'.MODl'ALOOMSKC.ciphei  h'xt.trne)  *). 

enureeeive  (*  -  (MODIALCOMSKC.VOlCI^COMSFO.eipboi  texl, raise)  *)} 

CTS  —  {encrypt,  decrypt} 

OCT  *  {(nii-traiuiiiiit.  encrypt),  (cin-roceivc,  decrypt)) 

MOHS  «  {RKDJVUDlO.  RKDJMCUTAL,  VOlCK-MOPFM,  MODKM-OOMSKO} 

Mos  {inp.iraiiMiiii-nimloK  (4  »  (MODMM-OOMSI'X’.RI.AC’K^ANALOd.cipliertext.tnie)  *), 

inp-transmit-iligiial  (*  «*  (MODlCNUCOMSICCJiLAf -K JddITAIi, ciphertext, true)  *), 
inp.trmisiuiuplnintcxt  (*  «-» (VO|OIC.AIODFM,niAOK_ANAl»OCJ1i»|jiint(\\tl(rm»)  *), 
mp-.rm*ivi\jmalog  (*  *  (1U.ACK_ANAIXX«, MOPKM-OOMSKO, ciphertext  .ThI-m*)  *). 
mp_receiv(!«<ligitnl  (*  ■  (lH,AOKJ)KiITAli,MOI)KM.C-()MSI,X'.ciphei text. false)  *), 
Jiip-J’eeeive^plainteXt  (*  *  (BhA( ’K_ANAIXX *.VO|( •F^MOni'JM.plainlexl.ral.v-)  *)} 

MTS  >■  {eiicofle-imxliilate.  •  l*,inu<iulnU,_<li,<-o(lr,  rnt'odr.  dectKle,  null) 

NK'T  a-  {(iMp..lraiisiuit.j»ni»lnjt.  encode. iikhIu late).  ( in p-transmit -digital,  encntle), 

(mp-ti'mismil-plaintext.  null).  (inp_receivo.nnalogp  deinodulate-tleoude), 

(iiip-m-eive-tligital,  decode),  {mp-reoeivu^plaiiitexl,  null)] 

OPR  -»  {(nimly/.c.  plain),  (synthesize,  plain),  yp« ,  cipher), 

(decrypt,  decipher).  (eiicode.iiuMluliite,  plain),  (encode,  plain), 

(deiuodulat<'_deoo«|e,  plain),  (decode,  plain),  (null,  plain)} 


Figure  5-1.  Inlcnial  Abstniel  \ l*» !<.•]  Iiitcriiroliilitin 


minin'  KlliiiilOiii.'oiiM  participation  uf  I lunp  events  sliuri'il  l).v  the 
process’  alphabets. 

ASVT  Verification 

The  id li'iii:i I  ASVT  sccurily  nuxlrl  is  iIip  inslnnlialion  of 
llie  iihslrnrl  iiilcriiill  securily  model  will,  I  In*  inli'lnnl  imnlel 
in t I'rpr.'t ut Ion .  Likewise,  llie  cxit'rnnl  ASVT  security  imxli'l  is 
tin1  iiiKl mil iul lost  ni  mi  nhslrmt  external  security  nualcl  tvilli  an 
ASVT  ulisirnel  imxli'l  iiitcrpiciaiMi  II  I-  Wrilicaliim  of  tin- 
AS\T  li'|n lii-e  proving  t  lini  l lip  ASVT  liiiiclionnl  s|)eril|eali"n 
conforms  lo  both  (lie  ASVT  exlernal  alul  inlernnl  security 
nnxlels.  A  itiniinnl  l’< <riiiul  vt-rilicn l ii>n  of  (lie  ASVT  using  tin* 
C  'SI i  proof  rules  introduced  in  |t>]  is  lixi  long  mill  detailed  for 
I'l'esenliilioii  In-re.  CSI*  does,  however,  simplify  lla*  task  or  infor¬ 
mally  arguing  I  hat.  llie  ASVT  eoliforins  lo  llie  .security  policy 
described  by  (la-  models. 

An  urgiiiiient  ( lint  the  ASVT  t'oiiforiiin  to  llie  internal  aeru- 
lily  policy  proceeds  by  induction  on  the  length  of  the  truce  of 
each  ASVT  component.  Rather  I han  prove  that  all  of  the  com- 
|s)iii'uts  meet  their  speeilienl  ion,  we  prove  only  the  mini  dillicult, 
('()'■  /.s/i ( [^\}( JlJl’l. /',  'flic  pr- of  of  (he  other  two  components 
proceed  snnilurly.  I, el  s  he  the  trace  for  CUMSKC-AIODVLli. 

Hi Lsl  (  disc  :  l.ct  s  ■ 

Then  all  <-. 

INCOMING—MK  (s,  ('.out-chan.  iiiitiuLkcy)  =  {} 

uml  OUTGOING-MK  (s,  c  oiil-i  lmn,  mil  nil  key) { j 

whii'h  implies 

CM_IIED_BLAC  K_S  EP  ARATIO  N  =  Hue 


so  trivially, 

coMsEcjitnnvi.EsM 

CN1JIED-J3LACK-SEPA1LATION  . 

luilmlion  Step  :  (l,e(  (a.  be  the  Iriu'e  append  ope  rat  ion.) 

Assume  llint 

coMsi:cjuoiHiu-:sn\ 

CM_ItED_BLACK_SElJARATION, 

Prove  dial 

all  t'tno  e  n('(  M I  SIX  '_A  1 01)1 7.  A-. 

ro,\fsi:r^\iai)i’i.Exa 

CM  -RE D_BL ACK-S EP  ARAT I O  Nri, ,, ,  . 

I’r,wf  :  CM_RED_BLACK_SEPAEATION  speeilies  that, 
when  not  in  plaintext  mode,  for  till  messages  m  (I)  if  m  is  output 
Irom  the  C'OMSEC '-AlODULE  via  some  conligiiration  then  it  is  a 
proper  trnnsformiilion  of  some  message  input  for  that 
con lign raliou,  (2)  if  m  is  input,  through  a  ehimnel  marked  black 
and  output  through  a  rhanncl  marked  red  it  must  be  encrypted, 
(•I)  il  in  is  input  through  a  channel  marked  red  and  output- 
through  a  channel  marked  black  it  must  be  decrypted,  and  (1)  if 
ill  is  input  and  output  through  channels  with  the  same  mark  it 
must  be  neither  encrypted  nor  decrypted.  The  only  events  in 
nVOMSECMODVU-:  that  allecl'  1NCOMING-MK  (or 
OUTGOING_MK)  are  those  that  input  a  message  (or  output 
a  message)  or  those  that  input  a  new  key  Noting  that  events 
dial  input  a  new  key  only  alfect  future  messages  it  is  trivial  lo 
prove  that 


I  nicr-MOCKSSOH'  = 

s-clcct—madc  m  —  YOICIU'HOCESSOII,. 

<  I  not  m  £  MS  I  '• 

\  OK  Vi  OC  I'/S^iOK^ .jI1_i-ilaillVOIfl':_Mt)l)I,:M1|'laintcxt1>‘4iiish_to-talk) 

-al  in  =  plaintext  £  e  piisli-io_tiilk  I  • 

voiau'i{on:ssoii[WivK 

v:  1  in  —  plaintext  *t  not  c.|iiisluiouXalk  I  * 
v  i  ;*  *>i]sh_tu-t-nik  I  ' 

»  >  7'—  I*IKK  A. \v»0/l*jvo|( •!•*„[•( iMSKCV .«MJlw1’liaii,l,i|*liertP-Vl.i,-|'iitH_(i‘_l:«lic) 

I  p//_  on  — ►  17W ‘ILI>K(K'!’^S()IE  •  I  c.pusli— talk  I  *  7 jll_C|miKt.  ,liril]r  ir,|,.) 

I  ,i IL.a]J—  VOU  'lU'KOt  ,»KlaM  •  I  <\pi!sli_to_tnlk  I.'  VOICIU’ROCKSSOK t 

I  l,oak~'i,iMM 


■  i  „0|  (,.|,i  e{Ui-:i'-M:i>io.  iii':i)J>K.iTAi^.v- eii-2 e)iii,AcK.ANAi. cm;,  iii,ac:kj)Ic;itai,}) 

V  (fill  »  KK|)_nl<:iTAI.  ,V  e.imxle  =  plaintext)  V  (ch2  =  B1,ACK JilGlTAL  *  c.motlc  =  pliiinlext  1? 

plaintext))  I  • 


\  ()I(  'l.L  *I\0(  ..j,| <Vi)|{,|-;„(r(»\|s'l,;(-1,Miiii,k.c.i'iisli_ii»..i:ilK) 

I  f.|>unlUiUalb  .t  Mil  =  KKD-DKlITAI,  V  (chi  =*  HKD-AUDIO  .V*  c.mocie 
l  ‘OK  ‘I'Ll 7i UK  'EsSi  m lO-Mc » nin.iM\|oisii_u>_i»ik) 

*  I  e.|)Usli_to_.t (ilk  .V  rlil  *  HKD-AUDIO  .V  e.inodr  » |»hiint«-xl  I  • 

l  ()K  'A— I  *!!()(  /vSM.ty l*(V<;|f*K_0  »MS|-XV!il.‘‘.HKi«k.**.|'iish..i*>_lHlk) 

■  |  nu(.  r.pu.sh-l.O:ilk  «\  (rlil  «  UKI>J)K UTAl.  V  (cl»l  -  RKD-AUDIO  .t  c.iikkIc  •  ■  plainloNt))  I , 

\  OK  'hmj  >ifO(  ,AtS.sO/i*jvn|cT 

I  (c.in-Hiuu  ?  niMjK  — *•  e.onl-rlisui  1  WT(«-)ih»*j{)  — *  I  OKHLi ‘hSSO/I,.)  • .  I  r  £  \  C  S  I  •  \  OK  E—l*! 1()(-hSS()he 
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INCOMING -MK  (sfa'tmo,  chan,  key)  = 
if  ci no  *■  chanTm 

1-lu‘ii  {m .key}  INOOMlNG_MK  (s.  clian.  key) 

else  INCOMING-MK  [s.  chan,  key) 

OUTGO  1NG_MK  (^tcino,  chan,  key)  = 
if  nun  ~  chanhn 

then  {ill .key}  jj  OUTGOING-MK  (s.  chan,  key) 
elw  OUTGOING-MK  (s.  chan,  key) 

By  (a3),  we  heed  to  ensure  only  llml  if  emo  is  n  communication 
event  then  (1),  {2).  (3),  mid  (-1)  are  true  for  all  possible 
configurations  of  C(  )\ISl£Cmm\l()l)UU£  in  which  the  mode  solve- 
tor  is  in  tlie  ciphertext  position.  (1)  is  true  since,  in  the  func¬ 
tional  specific  ii  i  ion  of  ( '()\  ISl'X  '_A  K)I)(  H.  ,  before 
(  C',r(e}(msglk)  may  he  output  over  c.oiit_jrlm»,  e  must  he  an  ele¬ 
ment  of  CCS  mid  uisg  must  he  input,  over  c.iii_cimli.  (2),  (3),  and 
(-1)  are  true  by  inspection  of  the  set  CCS  mid  the  functions  CllC, 
CCT.  and  (  DB  in  Figure  .VI.  /wn/  of  Proof 

An  iiiformal  argument  very  siniilar  in  this  one  can  he  used 
to  convince  oneself  I  hut  tie*  functional  .spceilicnl  inn  conforms  to 
the  external  security  policy.  These  arguments  increase  our 
confidence  llml  the  ASVT  functional  specification  conforms  to  its 
security  policy  Although  we  Lave  not  formally  verified  the 
ASVT  using  CSi\  initial  results  using  the  Gypsy  verification  sys¬ 
tem  |5j  suggest  that  it  is.  in  fad,  formally  verifiable. 

0.  CONCLUSIONS 

The  increased  use  of  software  in  the  development  of  COM- 
SftC  equipment  requires  techniques  to  assure  that  COMSKC 
software  meets  its  security  requirements.  Formal  spec ilim lion 
and  veriliealion  provides  n  promising  approach  to  meet  the  secu¬ 
rity  assurance  needs  of  COMsKC  software.  The  practical  appli- 
eation  of  thin  apprune!)  requires  mi  analysis  of  existing  forum! 
speeilicnlloll  mid  Ve| iliciit|o|)  techniques  to  determine  Ilnur  suita¬ 
bility  lor  verifying  (hat  COMShlC  sofiwiuo  meets  its  security 
HMjiiirenieiils  But  her  than  evaluating  verification  systems  m 
general.  We  have  taken  the  approach  of  comparing  verification 
systems  for  a  specific  class  of  applications  and  class  of  properties 
to  be  proved.  A  lioiil l ivinl  COMSEC  system,  represent ing  the 
class  of  applications,  mid  a  security  policy  for  the  system. 
ie  present  ing  the  class  of  properties,  has  been  formally  specified  in 
CSl1  The  csr  specificut i<  >n  of  the  \S\'T  deitioiisl rates  the 
feasibility  of  applying  formal  speeilicntiou  technique*  to  (’DM- 
S|)( '  i system  designs  and  provides  a  vehicle  from  which  to  study 
and  cot 1 1 pa i c  systems  for  verifying  COMSlvC  software. 

Many  coiiipiiler  security  and  verification  experts  agree  t hut 
a  system's  security  policy  need  l>e  staled  only  in  terms  of  the 
interlace  bet  ween  the  sv'slem  and  Ms  external  environment  ’  I.*1 
No  reference  |o  the  111 t I’lllll I  structure  of  the  system  should  be 
necessary  While  computer  security  policies  typically  state 
requirements  «»n  the  flow  of  uir<irmn(!ni:  between  the  device  and 
the  user,  COMSl’X’  semriiy  policies  typically  slate  reiiuiremenls 
on  the  How  of  informal  ion  between  devices  nr  processes. 
Speciliniliou  of  COMSKC  security,  therefore,  often  does  require 
reference  to  the  internal  structure  of  the  system.  |'*»r  ins? mice, 
tin-  ASVT  seen i tty  policy  requires  control  on  the  information 
flow  from  the  voice  processor  to  the  modem  processor. 
Specification  of  1  his  property  requires  knowledge  of  I  lie  infernal 
structure  of  the  ASVT.  COMSKC  systems,  in  general,  must 
enforce  both  mi  external  security  policy,  slating  restrict  ions  on 
information  Hows  between  the  device  nnd  the  outside  work!,  and 
an  internal  security  policy,  stating  rest iicl ions  on  information 
flows  between  the  processes  internal  to  the  device. 

Toward  the  goal  of  assuring  ( 'OMSl'X '  soft-ware  security,  it- 
appears  that  formally  verifying  flint-  a  nontrivial  ('SB  process 
description  meets  its  specification  is  too  cumbersome  i*«  carry 
through  without  automated  assistance.  A  formal  proof  that  the 
ASVT  conforms  to  its  security  policy  explodes  mio  n  great 
number  of  cases  that  unild  In*  handled  with  speed  and  accuracy 


using  a  mechanical  verification  system.  Since  our  goal  is  to  sur¬ 
vey  existing  verification  techniques,  rather  than  engineer  new 
ones,  we  leave  formal  verification  up  lo  existing  automated  tech¬ 
niques.  Nevertheless,  there  are  a  number  of  significant  advan¬ 
tages  that  have  arisen  from  using  OSB  in  this  project.  During 
the  formulation  of  the  ASVT  example,  CSl*  provided  insight  into 
aspects  of  the  asynchronous  communication  of  processes  within 
the  ASVT  that  were  not.  immediately  obvious  from  its  informal 
description.  The  language  also  provided  a  concise  medium  for 
review  of  ASVT  functionality  and  security  policy.  The  OSB 
specification  allowed  us  to  informally  convince  ourselves  that  the 
ASVT  process  description  conforms  to  its  security  policy. 

Ail  important  lesson  learned  while  trying  to  formalize  the 
ASVT  in  CSP  is  that  the  strength  of  (-SB  lies  in  its  fundamental 
concepts  and  operations.  Home's  book  presents  the  basic  con¬ 
cepts  or  the  (’SB  theory  in  an  intuitive  manner  and  then  builds 
on  the  theory  by  defining  new  operations  from  previously  defined 
ope  rations.  We  quickly  became  overwhelmed  by  the  wealth  of 
notation  contained  in  his  hook.  After  floundering  lor  awhile,  we 
discover'd  that  a  combination  of  sei  theory,  arithmetic,  mid  the 
most  niiidainenlal  concepts  mid  operations  of  (SB  is  sufficient  to 
formally  specify  a  broad  range  of  systems.  With  this  realization 
progress  mine  more  readily. 

Kill ure  objectives  of  (his  project  are  lo  investigate  existing 
automated  formal  veriliriit  ion  techniques  and  lo  demoiisl rale  and 
document  the  use  of  these  techniques  bv  verifying  that  the 
ASVT  satisfies  its  security  policy.  The  < ’SB  specification  of  the 
ASVT  serves  as  a  concise  description  I'm  an  which  different  teams 
1 1 1  a  \  pm  sue  tlie  fomml  verification  ,»|  a  system  n  parallel,  with  a 
high  degree  of  conlidence  that  they  are  all  wm-  Hi  from  a  com¬ 
mon  understanding  of  the  problem.  We  have  already  begun 
specifying  the  ASVT  using  Gypsy  |-r>i.  mKVKS  1 1 1.  and  KDM  j#|. 

These  veiilienlioii  systems  will  he  compared  for  their  ability  lo 
promote  ( ‘OMSI’X’  software  security. 
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Abstract 

An  approach  to,  and  progress  toward,  t he  addition  of  Ada  program 
verification  capability  to  the  State  Delta  Verification  System  (SDVS) 
are  presented.  In  the  past,  SDVS  lias  been  used  extensively  to  verify 
the  microprogrammed  implementation  of  computer  instruction  sets 
written  in  the  computer  description  language  ISi’S.  The  generality 
and  modularity  of  SDVS  permit  its  convenient  extension  to  other 
programming  languages  and  verification  applications.  A  plan  for  the 
incremental  adaptation  of  SDVS  to  a  series  of  Ada  subsets  of  increas¬ 
ing  semantic  complexity  is  outlined.  The  simplest  of  these  Ada  sub¬ 
sets  is  called  ( ore  Ada.  Interfacing  a  new  language  to  SDVS  requires 
constructing  a  translator  from  that  language  into  state  deltas,  width 
are  the  semat  tic  iiasis  of  SDVS.  A  general  strategy  for  constructing 
such  translators  via  their  denotational  semantic  specification  and  a 
straightforward  manual  translation  of  the  specification  into  a  Com¬ 
mon  l.isp  program  are  presented,  and  the  successful  application  of 
this  strategy  to  (lore  Ada  is  reported.  Future  work  on  Core  Ada  and 
more  complex  Ada  subsets  is  discussed. 


1  Introduction 

'I'll is  paper  describes  an  approach  to  adding  Ada  program  verifi¬ 
cation  capability  to  the  State  Delta  Verification  System  (SDVS). 
SDVS  was  developed  in  the  Computer  Science  Laboratory  of  The 
Aerospace  Corporation  and  a  production-quality  version  fur  iikc  in 
microprogram  verification  lias  recently  been  completed.  That  version 
of  SDVS  is  specialized  for  the  verification  of  the  microprogrammed 
implementation,  written  in  the  computer  description  language  ISI’S, 
of  computer  instruction  sots.  SDVS  is  general  and  modular  enough 
to  be  adapted,  with  a  reasonable  amount  of  effort,  to  other  verifi¬ 
cation  applications  and  programming  languages.  Our  plan  lor.  and 
progress  toward,  adapting  SDVS  to  Ada  are  presented. 

SDVS,  state  deltas,  and  the  translation  of  Ada  statements  into  state 
deltas  are  briefly  described  In  Section  2.  Next,  our  plan  for  adapting 
SDVS  to  Ada  verification  is  presented  In  Section  3.  Central  to  this 
plan  Is  the  incremental  adaptation  of  SDVS  to  a  series  of  Ada  subsets 
of  increasing  semantic  complexity.  Au  overview  of  the  simplest  of 
these  subsets,  Core  Ada,  is  given  in  Section  4.  Section  5  presents  our 
approacli  to  the  design,  specification,  and  rapid  implementation  of 
the  SDVS  Ada  translators,  a  discussion  of  our  experience  with  the 
Core  Ada  translator,  and  required  additions  to  the  SDVS  inference 
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Figure  1:  Structure  of  tlie  State  Della  Verification  System. 


engine.  Finally,  in  Section  (i  we  discuss  the  research  and  iinplcmcn- 
talicm  issues  relevant  to  adapting  SDVS  beyond  Core  Ada,  future 
prospects,  and  conclusions. 


2  The  State  Delta  Verification  System  (SDVS) 

A  good  general  introduction  to  SDVS  is  given  in  [1],  even  though 
some  information  specific  to  an  older  version  of  SDVS  is  found  tliuru. 
Some  of  the  following  description  of  SDVS  is  taken  from  [2],  where 
much  more  detail  about  SDVS  can  be  found.  The  structure  of  SDVS 
is  shown  in  Figure  1.  It  is  highly  modular;  the  components  of  most 
interest  to  us  are  the  simplifier  and  the  translators,  as  they  are  the 
components  most  affected  by  the  enhancement  of  SDVS's  verification 
capability  as  a  result  of  the  addition  of  new  programming  languages. 

SDVS  is  a  system  for  checking  proofs  about  tho  course  of  a  compu¬ 
tation.  SDVS  is  based  on  a  specialized  form  of  temporal  logic  whose 
formulas  are  called  state  deltas.  Technically,  SDVS  checks  proofs  of 
state  deltas,  which  provide  an  operational  semantic  representation  of 
computation.  SDVS  can  handle  proofs  of  claims  of  the  form  “if  P  is 
true  now  then  Q  will  become  true  in  the  future".  If  P  is  a  program 
(perhaps  with  some  initial  assertions)  and  Q  is  an  output  assertion, 
then  the  above  claim  is  an  input-output  assertion  about  P.  SDVS 
can  also  handle  claims  of  the  form  “if  P  is  true  now  then  Q  is  true 
now”.  In  this  case  if  P  is  a  program  and  Q  is  a  (specification  then  the 
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claim  assorts  the  total  correctness  of  P  with  respect  to  Q.  SDVS  is 
also  capable  of  handling  proofs  that  one  program  correctly  imple¬ 
ments  another*  i.c.,  multilevel  correctness  proofs. 

Central  to  SDVS's  behavioral  model  are  places  (which  can  be  viewed 
as  abstract  memory  locations  or  even  program  variables)  that  contain 
(abstract )  values,  the  places'  “contents".  In  its  simplest  form,  a  state 
(of  a  computation  or  a  machine)  is  an  association  of  places  with  their 
content*.  SI) \  S’s  plan-  fable  records  a  state. 

A  computation  is  specified  by  a  state  delta  or  sot  of  state  deltas  as 
a  sequence  of  state  changes.  The  application  of  state  deltas  to  ef¬ 
fect  state  changes  is  a  form  of  symbolic  execution.  One  can  facilitate 
compact  desciiptions  of  computations  by  including  in  state  deltas  a 
specification  of  which  places  potentially  receive  new  contents.  Sup¬ 
pose  that  a  state  delta  induces  a  change  from  a  state  about  which 
P  is  true  to  another  about  which  Q  is  true.  Then  assertions  true 
in  the  P-state  about  the  contents  of  places  whose  contents  do  not 
change  are  still  true  in  the  Q-statc.  If  it  is  specified  that  tw  places 
can  change  their  contents  as  the  stale  changes  from  P  to  Q,  then 
Q  must  be  true  in  the  state  satisfying  P;  this  is  simply  the  static 
assertion  ill  at  P  implies  Q. 

The  user  "‘tumimicnlcs  with  SDVS  through  several  languages.  The 
mm  i*  inttrfncv  language  is  used  for  interactive  proof  construction. 
The  proof  tumjuntjc  is  used  to  write  a  proof  for  the  system  to  check. 
The  state  delta  language  is  used  to  express  claims  to  be  proven  and 
to  describe  the  relevant  programs  and  specifications.  Finally,  the 
programming  languages  (currently  ISPS  and  (’ore  Ada)  are  used  to 
express  the  computational  objects  to  he  verified.  The  translators 
function  as  SDVS's  interface  to  these  languages  by  translating  them 
inio  i  he  stale  delta  language. 

The  proof  language  consists  of  two  parts:  NfriftV  and  dynamic.  The 
static  part  deals  with  proving  that  certain  assumptions  imply  cer¬ 
tain  conclusions  about  a  given  stale.  For  simple  theories  the  SDVS 
sunplijie r  can  automatically  prow*  these  claims  without  any  user  as¬ 
sistance.  The  dynamic  part  controls  the  state  transitions  made  by 
the  system;  it  contains  constructs  for  proof  by  symbolic  execution 
for  straight  -line  code,  proof  by  cases  for  conditional  branches,  and 
proof  by  induction  for  loops. 

2.1  State  Deltas 

I, et  £  be  a  first-order  logic  that  includes  constant  symbols  called 
plans.  £  is  two  soiled  (with  sorts  place  and  domain);  the  lirst 
Mill  denotes  i  ho  places  and  the  other  denotes  the  domain  of  values 
contained  by  the  places.  Let  A  be  a  two-sorted  model  for  C  in  which 
the  places  are  iutcrpictcd  as  themselves.  A  is  called  a  base  model  for 
l' .  Furl  her,  assume  that  /.'  is  augmented  with  names  (interpreted  as 
themselves)  for  all  domnin-eleuients  of  A.  Tills  provides  convenient 
support  for  using  C  in  applications,  such  as  SDVS,  involving  symbolic 
execution.  Strictly  speaking,  the  augmented  language  ought  to  be 
called  £j.  but  explicit  mention  of  A  will  often  be  omitted  in  the 
sequel. 

Let  there  be  two  function  symbols,  .  (“dot”)  and  ft  (“pound”) 
of  type  place  — *  domain,  not  in  £.  Let  £(.)  and  £(.,  ft)  de¬ 
note,  respectively,  £  augmented  with  dot,  and  £  augmented  with 
dot  and  pound.  Dot  and  pound  are  interpreted  in  £(.)-  and  £(., 
ft)- struct ures  as  functions  that  yield  the  contents  of  a  place. 

A  state  delta  (SI))  is  a  special  formula  of  the  form  [SD  P,  C ,  A/,  Q ] 
where 


•  P,  the  SD’s  precondition ,  is  a  boolean  combination  of  £(.)- 
formulas  and  state  deltas; 

•  C  and  A/,  the  SD’s  comodification  and  modification  lists,  re¬ 
spectively,  are  lists  (denoting  sets)  of  places; 

•  Q ,  the  SD’s  postcondition^  is  a  boolean  combination  of  £(.,#)- 
formulas  and  state  deltas. 

The  modification  and  eomodification  lists  are  often  called  mod  and 
coinod  lists  for  short.  Note  that  this  syntactic  specification  of  SI)s 
is  recursive;  the  basis  for  the  construction  of  SDs  consists  of  those 
SDs  whose  pro-  and  postconditions  contain  no  SDs.  SDs  are  also 
displayed  as  [SD  pra:  P  comod:  C  mod:  A/  post:  Q].  Fro-  and 
postconditions  are  often  represented  by  lists  of  formulas;  the  list 
represents  the  logical  conjunction  of  its  elements.  The  state  delta 
language  £si)  is  the  set  of  all  boolean  combinations  of  £(.)•  formulas 
and  stale  deltas. 

State  deltas  are  the  formulas  of  a  variant  of  temporal  logic,  in¬ 
terpreted  as  follows.  A  computational  model  for  £a,SU  is  a  pair 
M  -  (7\  {aijier)  where 

•  T  is  a  totally  ordered  set  (representing  time)  with  a  least  ele¬ 
ment;  and 

•  for  each  /  €  7\  <rt  :  -»  Almnnin  i-s  <l  f miction  that,  gives 

the  contents  of  each  place  at  time  t. 

V  is  called  the  time  line  of  M.  For  any  l  £  7’,  <jt  is  called  a  state 
«»f  Ms  and  for  any  place  />,  =  &t{p)  denotes  the  contents  of  p 

at  lime  /.  Note  that  we  can  write  pA  simply  as  since  places  are 
interpreted  in  A  as  themselves. 

The  truth  value  of  Ca.sd -formulas  is  defined  as  follows.  Let  M  - 
(7‘.  {rt>} !£•/■)  be  a  computational  model  for  £a,sd*  A  base  model  A 
can  be  extended  in  two  fundamental  ways: 

•  for  each  f  G  7’,  At  denotes  an  £(.)•  model  extending  A  such 
that  . A '  -  <rt\ 

•  for  each  /i  <  /•?  T.  All%t7  denotes  an  £(.,  #)-mode!  extending 

A  such  that  =  crj(  and  ftAn.e,  ~  aii. 

Let  /|  <  /;  G  7’ and  let  denote  the  corresponding  dosed  (time) 
interval.  A  place  p  is  T -preserved  «wr  [/| •  /*)  if  for  all  t{  c  /,T  <: 

h^dv)  •-  (Tfipb 

Let  0  be  an  £:*/?•  formula  and  M  a  computational  model.  Let  /(>.  t\Ji  C: 
/’,  where  fo  <  / 1  <  tj.  We  now  define  what  it  means  for  M  to  satisfy 

0  at  /n  £  7\  denoted  |=y^,f0  0.  (To  do  this,  all  auxiliary  notion  of 

satisfaction,  denoted  |=,vuj iti  0,  must  be  mutually  defined.)  Thus, 

1.  if  0  is  an  C(.)-fornmla,  then  |=  ma0  4>  HV  ]=.4,0  */>; 

2.  if  0  in  an  £(.,#)-formuia,  then  h-x.f,./,  o>  ilF  0; 

JL  if  0  ib  a  state  delta  [SD  P,  C\  A/,  Q ] ,  then  |=A^,i0  0  iff  for  every 
/l  >  io  such  that  |=yw,i,  P  and  all  places  p  €  C  are  7'- preserved 
over  (/0di|,  there  exists  I2  >  t\  such  that  |~/vili|1ia  Q  and  all 
places  p  <$.  M  are  7  - preserved  over  [(id?]; 

A.  I -M.ii.t2  ESD  ^CsMsQl  i CSD  P,C,A/,g]; 

5.  for  an  arbitrary  Csty formula,  |— M,ir>  and  |~M.f|.ia  we  extended 
over  the  boolean  connectives  in  the  standard  way. 
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Aii  SI)  is  a  description  of  a  transition  from  one  computation  state 
to  another.  Its  precondition  describes  ;•  stale  from  which  the  transi¬ 
tion  ran  he  made,  and  its  past  condition  describes  the  state  resulting 
from  tin'  transition.  The  times  fj  and  t?  above  are  called  the  SI)\s 
prr'Viuhtinn  an<l  postcondition  time,  respectively.  An  SD’s  mod  list 
M  specifies  those  places  whose  contents  arc  allowed  to  change  be¬ 
tween  precondition  and  postcondition  time  as  a  result  of  the  tran¬ 
sition.  The  truth  value  of  any  assertion  about  these  places  cannot 
In  assumed  io  be  preserved  during  the  transition.  The  contents  of 
places  not  listed  in  the  mod  list  must  remain  unchanged  during  the 
slate  transition.  The  quantification  “there  exists  t?  >  t/’  in  clause 
d  above  asserts  that  the  entity  described  by  the  SD  performs  its  de¬ 
scribed  stale  transition  in  a  finite  amount  of  time.  Thus  SDs  assort 
the  total  correctness  { in  the  Floyd -Hour?  sense)  of  programs  whose* 
transitional  behavior  they  characterize  with  respect  to  the  SI)  p ro¬ 
und  postconditions  (together  with  the  implicit  assertions  that  tin* 
places  in  SI)  mod  lists  preserve  their  contents  across  the  associated 
state  transitions). 

The  role  of  an  SD’s  coniod  list  C  is  more  subtle  and  is  best  explained 
within  the  con  lex  I  of  the  SDVS  system.  SDVS  assumes  the  existence 
of  a  computational  model,  and  maintains  a  current  time  t  and  an  as- 
Micialed  current  stair  <rf.  A  Inn*  SI)  in  applicable  ill  the  current  state 
if  its  precondition  is  true  in  the  current  state.  If  several  Sl)x  are  ap¬ 
plicable  at  a  given  time,  then  the  prover  lias  the  option  of  selecting 
which  of  these*  SDs  to  apply.  When  an  Si)  is  applied,  the  state  trail  - 
si t ion  that  it  describes  occurs  ami  its  postcondition  becomes  true. 
The  current  lime  is  advanced  to  that  SD’s  postcondition  time  and 
•  In'  state  of  the  computation  is  updated,  it  is  important  to  note  the 
following  facts: 

•  As  long  as  the  contents  of  all  places  in  its  coiund  list  remain 
unchanged,  a  true  SD  will  remain  true  and  thus  applicable  any 
time  its  precondition  is  true. 

•  If  the  contents  of  any  place  in  u  true  SD’s  comod  list  have  pos¬ 
sibly  been  changed,  then  t  he  truth  of  that  SD  is  not  necessarily 
preserved,  i.o.,  its  truth  becomes  indeterminate.  Since  such  an 
SD  is  not  guaranteed  to  be  true,  it  is  no  longer  applicable  even 
if  its  precondition  is  true. 


The  foregoing  definition  of  state  deltas  is  essentially  that  of  [,'!),  How 
ever,  the  SDs  actually  implemented  in  the  SDVS  si.tein  are  more 
general.  In  particular.  SDs  and  their  pre«  ami  postconditions  can 
contain  quniililirntion.s  of  individual  variables  of  both  sorts  place 
and  domain.  Quantifications  of  domain-variables  are  used  in  pro- 
grain  specifications.  The  existential  quantification  of  place-variables 
is  us,  d  in  SDs  produced  by  l  he  translation  of  Ada  block  .statements  to 
represent  the  introduction  and  subsequent  deletion  of  program  vari¬ 
ables  upon  block  entry  ami  exit,  respectively.  Also,  the  operators  dot 
and  pound  map  places  to  place* values  as  well  as  to  domain-values. 
The  precise  definition  and  investigation  of  the  properties  of  general 
SDs  are  subjects  of  ongoing  research. 

In  the  SDVS  system,  SDs  known  to  be  true  are  called  usable,  other¬ 
wise  (e.g.,  when  their  truth  is  indeterminate),  they  are  not  usable  and 
SDVS  delete*  them  as  candidates  for  application.  The  operation  of 
applying  of  SDs  can  be  used  to  execute  a  computation.  If  a  true  SD 
is  applied  and  has  other  SDs  in  i l s  postcondition,  then  these  latter 
SDs  become  true  and  can  themselves  be  applied  to  further  advance 
ilie  computation,  'lb  execute  purely  sequential  computations,  it  is 
sufficient  to  require  that  ( t)  when  an  SD  is  applied  its  truth  always 
becomes  indeterminate,  rendering  it  inapplicable,  and  (2)  the  truth 
of  any  other  S Ds  that  were  true  at  the  same  time  that  the  applied 
SI)  was  true  also  becomes  indeterminate.  Let  ALL  be  a  special  place 
denoting  (the  list  of)  all  places.  Thu  any  usable  SD  whose  conical 


list  contains  ALL  and  whose  mod  list  is  nonempty  becomes  unusable 
when  it  or  any  other  usable  SI)  is  applied.  To  this  end,  the  comod  list 
of  every  generated  SI)  is  (ALL)  and  the  mod  fist  of  £  eery  generated 
SD  is  made  nonempty  by  the  inclusion  in  it  of  a  unique  place  pc  that 
denotes  an  (implicit)  program  counter.  Thus  the  truth  of  any  usable 
.SI)  will  become  indeterminate  when  it  or  any  other  SD  is  applied. 


2.1.1  Translating  Core  Ada  Statements  Into  State  Deltas 

Several  examples  of  the  translation  of  Core  Ada  statements  into  state 
deltas  wifi  he  given  in  this  section.  Provided  that  the  value  of  A 
is  greater  than  zero  beforehand,  the  conditional  execution  of  the 
assignment  statement  A  :=  A  ♦  1  is  translated  into  the  following 
SI): 

[SD  pro:  (.A  GT  0) 

comod:  (ALL) 
mod:  (pc,  A) 

post:  (#A  *  .A  +  1)3 


Because  the  assignment  changes  A's  contents,  this  SI)  would  be  i/i- 
consistmt  it  A  were  not  in  its  mod  list.  Once  this  SD  is  applied,  it 
becomes  unusable. 

Subject  to  the  condition  B till  <  10,  the  assignment  I3[T]  :=  B[I] 
+  ?  is  translated  into 


[SD  pro:  ( . B[ . I]  LT  10,  .1  GE  .B\FIRST,  .1  LE  . B\LAST) 

comod:  (ALL) 
mod:  (pc,  B[.I]> 

post:  -  -UC.I]  +  2)3 


This  example  indicates  that  places  can  be  struefund ,  with  compo¬ 
nents  that  are  themselves  places.  In  this  case  the  place  B  lias  array 
si  curt  me  and  is  indexable.  The  places  B\FIRST  and  B\LAST  contain 
the  current  value  of  B’s  lower  ami  upper  index  bounds.  Tim  formulas 
.1  GE  . B\FIUST  and  .1  LE  . B\LAST  in  Hie  precondition  of  this  HI) 
an  as  guards  against  the  raising  of  a  <()N\STRAINT.KRR0R  ex¬ 
ception,  by  making  this  Si)  inapplicable  if  either  is  false.  Note  that 
only  the  I  t li  element  of  B,  rather  than  the  entire  array  B.  is  in  the 
SD's  mod  list,  because  only  that  element  of  B  is  modified  in  this  state 
t  raiisition. 


The  above  examples  illustrate  translation  of  statements  “out  of  con¬ 
text’'  in  lie*  sense  that  the  larger  program  in  which  they  are  embed¬ 
ded  is  not  considered.  The  following  examples  will  take  context  into 
account,  therein  more  -learlv  underscoring  the  i  neremt  nlal  n  a  I  are 
of 'ihe  translation.  Tlieromliiion.il  statement  if  B Cl J  >  0  then  A 
:*  0  else  A  :*  1  end  if  is  translated  into  two  SDs: 


[SD  pro: 
comod : 
mod : 
post : 


GT  0, 

(ALL) 

(pc) 

(  contl  )] 


.  I  GE  , B\Fi|tST ,  ,1  LE  .B\LAST) 


[SD  pro : 
comod : 
mod : 
post : 


(~(  .B[ .  IJ  GT  0).  .1  GE  .BNFIRST,  .1  LE  . B\LAST) 
(ALL) 

(pc) 

(  cotit2  )] 


when'  denotes  logical  negation,  and  contl  and  cont2  are  contin- 
ualiuns  that  iji  m  nilL  the  translations  of  the  assignment  statements 
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A  :«  0  and  A  :»  1,  respectively.  It  is  important  to  emphasize  that 
contl  and  cont2,  despite  their  appearance  in  the  postconditions  of 
SDs,  are  not  formulas  themselves,  but  rather  are  continuations  that 
generate  formulas  (containing  SDs  that  thereby  become  usable)  that 
those  continuations  represent.  This  is  the  sense  in  which  the  SDVS 
translators  are  incremental ;  additional  translation  of  a  portion  of  a 
program  occurs  only  when  that  portion  is  “reached”  by  the  appli¬ 
cation  of  an  SD  and  the  additional  translation  is  initiated  by  the 
corresponding  continuation  contained  in  the  postcondition  of  the  ap¬ 
plied  SD.  If  both  of  the  above  SDs  are  applicable  and  the  first  of 
them  is  applied,  its  postcondition,  which  contains  contl,  becomes 
true.  Thereafter,  both  of  the  above  SDs  become  unusable  because 
of  the  intersection  of  (ALL)  and  (pc).  A  similar  statement  can  be 
made  when  the  roles  of  the  above  SDs  are  reversed.  The  treatment 
of  the  above  two  SDs  requires  a  proof  bp  cases  in  an  associated  SDVS 
proof. 

The  statements  while  A  >  0  loop  loop-body  end  loop  ;  next-statement 
are  translated  into  the  following  SDs: 

sdl  -  [SD  pra:  (.A  GT  0) 

comod:  (ALL) 
mod:  (pc) 

post,:  (  contl  )J 

sd2  -  [SD  pra:  (*(.A  GT  0)) 

comod:  (ALL) 
mod:  (pc) 

post:  (  cont2  )] 

These  SDs  represent  the  two  possible  outcomes  of  evaluating  the  loop 
test  A  >  0.  sd2  allows  the  loop  to  be  normally  terminated;  the  con¬ 
tinuation  cont2  initiates  the  the  translation  of  next- statement,  udl 
represents  the  ease  where  loop-body  is  executed  followed  by  another 
evaluation  of  the  loop  test  to  determine  whether  further  loop  itera¬ 
tions  arc  required.  The  continuation  contl  represents  the  translation 
of  looi>-botly ,  which  may  be  a  complex  statement.  The  postconditions 
of  the  ultimate  SDs  in  the  translation  of  loop-body  will  contain  contin¬ 
uations  that  legeuerate  sdl  and  sd2;  in  th' .  sense  sdl  is  recursively 
defined.  The  appearance  of  such  recursively  defined  SDs  requires  the 
use  of  induction  in  associated  SDVS  proofs. 

The  block  statement  declare  x:  integer;  begin  body  end;  is  trans¬ 
lated  into  the  existentially  quantified  SD 

sdl  -  (3x)[SD  (TRUE) 

(ALL) 

(pc) 

(ALLDISJQINT(pnama,  .pnama,  x) ,  sd2)] 

whore 

Sd2  *  [SD  (TRUE) 

(ALL) 

(pc,  pnaina,  x) 

(COVERING (Apnama,  .pname,  x) ,  contl)] 

Application  of  the  state  delta  sd2  elaborates  the  declaration  x:  in¬ 
teger;  .  The  continuation  contl  represents  the  translation  of  body, 
the  postconditions  of  the  ultimate  SDs  of  this  translation  contain 
continuations  that  represent 


Sd3  »  [SD  (TRUE) 

(ALL) 

(pc,  pname,  x) 

(COVERING! .pname,  Apnama,  x) ,  cont2)] 

cont2  continues  incremental  translation  and  symbolic  execution  to 
the  block’s  successor.  The  block  statement  introduces  new  variables 
into  an  Ada  program,  and  the  corresponding  SD  introduces  new  as¬ 
sociated  places.  When  this  block  is  entered  during  execution,  the 
declaration  of  the  program  variable  r  i-  elaborated,  sdl  asserts  the 
existence  of  a  new  place  x  by  the  suitable  quantification  of  sdl;  this 
new  place  x  is  added  to  the  program's  universe  of  places,  repre¬ 
sented  by  the  unique  place  pname.  sdl’s  postcondition  then  asserts 
that  the  universe  of  places  pname,  the  places  that  it  contains  (de¬ 
noted  .pname),  and  the  new  place  x  are  all  mutually  disjoint.  sd2 
then  indicates  in  its  mod  list  that  the  contents  of  pname  and  x  have 
changed,  the  former  because  of  its  annexation  of  x,  and  the  latter 
through  implicit  initialization.  sd2’s  postcondition  asserts  that  the 
new  contents  (Apnama)  of  the  universal  place  consists  of  the  disjoint 
union  of  its  old  contents  ( .pname)  and  the  nev  place  x.  (The  reader 
is  reminded  at  this  point  that  ail  newly  introduced  place  names  are 
fully  qualified  by  the  path  in  the  tree-structured  environment  that 
loads  to  the  program  unit  in  which  they  arc  introduced.)  This  pre¬ 
vents  any  troublesome  equality  of  place  names.  The  application  of 
sd3  “reverses"  the  introduction  of  the  new  place  x.  Tills  reversal  is 
an  event  that  occurs  upon  block  exit.  To  accomplish  this,  sd3’s  mod 
list  indicates  that  the  contents  of  pname  and  x  have  (again)  changed, 
and  its  postcondition  withdraws  x  from  the  program’s  universe  of 
places  by  asserting  that  the  “old”  universe  .pnama  (containing  x)  is 
the  disjoint  union  of  the  “new”  universe  Apnama  (with  x  withdrawn) 
and  the  withdrawn  place  x. 

The  above  descriptions  are  not  a  complete  portrayal  of  the  trans¬ 
lation  of  loop  and  block  statements.  The  potential  occurrence  of 
exit  statements  in  the  bodies  of  loops  and  blocks  must  be  accommo¬ 
dated.  This  i3  done  by  building  an  execution  stack  which  upon  loop 
and  block  entry  receives  a  corresponding  element  that  can  be  invoked 
to  achieve  the  proper  completion  of  the  execution  of  the  statement, 
l.oop  statements  are  of  course  the  only  statements  that  can  lie  ex¬ 
plicitly  completed  by  an  oxil  statement,  but  loops  can  contain  blocks 
that  must  also  be  completed  prior  to  the  exiting  of  the  loops  that 
contain  them.  The  execution  stuck  elements  corresponding  to  blocks 
are  invoked  to  withdraw,  via  the  process  described  above,  places  in¬ 
troduced  at  block  entry.  Such  elements  are  invoked  if  their  blocks  are 
left  via  an  exit  statement,  in  order  to  effect  the  necessary  adjustment 
of  the  program’s  universe  of  places.  Upon  loop  and  block  comple¬ 
tion,  either  via  an  exit  statement  or  otherwise,  the  corresponding 
element  is  popped  from  the  execution  stack.  If  an  exit  statement 
leaves  several  intervening  loops  and  blocks,  then  each  is  left  in  turn, 
innermost  outward,  and  the  execution  stack  is  appropriately  popped 
as  this  process  proceeds.  The  precise  details  of  this  process  are  too 
complex  to  be  presented  here;  see  [4). 


3  Adding  Ada  to  SDVS 

SDVS  has  been  successfully  used  to  verify  that  ISPS  programs  are 
correct  with  respect  to  state  delta  specifications  of  their  behavior  and 
to  demonstrate  an  implementation  relation  between  two  ISPS  pro¬ 
grams.  Given  these  successes,  it  is  reasonable  to  investigate  next  the 
applicability  of  SDVS  toother  programming  languages,  in  particular, 
to  Ada  (5). 

The  verification  of  Ada  programs  will  be  a  new  application  area 
for  state  deltas  and  SDVS.  Prior  work  on  Ada  verification  has  been 
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■.lone  elsewhere  [G,7],  Our  additional  contribution  to  this  body  of 
research  will  be  to  apply  SDVS’s  unique  features  to  (a)  prove  the 
loin!  correctness  of  Ada  programs  with  respect  to  specifications,  and 
(hi  do  multilevel  verification  of  Ada  programs.  Two  such  level?  of 
verification  could  bo  (1)  proving  the  correctness  of  an  Ada  program 
with  respect  to  a  high-level  specification,  and  (2)  proving  that  the 
lincroprogi amiiied  implementation  of  the  compiled  Ada  program  is 
a  correct  implementation  of  the  Ada  source  program. 

3.1  Ada  Verification  in  SDVS 

In  order  to  apply  SDVS  to  the  verification  of  Ada  programs,  there  are 
several  research  and  implementation  issues  that  must  be  addressed. 

3.1.1  Research  Issues 

file  principal  research  issues  that  must  be  addressed  in  adapting 
SDVS  to  the  verilication  of  Ada  programs  are  (1)  defining  the  so- 
mant ic» of  Ada  ( more  precisely,  the  subsets  of  Ada  in  which  verifiable 
Ada  programs  will  lie  written),  and  (2)  augmenting  the  SDVS  sim- 
plitier  and  data  type  theory  repertoire  with  components  necessary  to 
support  the  Ada  language. 

Our  approach  is  to  specify  and  implement  translators  from  verification- 
oriented  subsets  of  Aila  into  state  deltas.  Moreover,  the  transit, tor 
»pei  iiic.it ion  should  be  precise  and  straightforwardly  transformable 
into  a  corresponding  implementation.  This  will  provide  not  only  an 
iiiiplemeiital ion-oriented  formal  specification  of  the  Ada  translator, 
but  also  a  lormal  semantics  of  the  Ada  subsets  in  terms  of  state 
deltas.  I  bis  specification  will  also  provide  the  precise  and  accessi¬ 
ble  documentation  necessary  for  the  construction  of  a  reliable  Ada 
M-rilM-ation  system.  An  initial  experiment  toward  these  goals  was 
mu  lot  uial  speeilii  ation  of  the  translation  of  ISPS  into  state  deltas 
Is],  1  lie  associated  research  issues  ale oftour.se  writing  the  translator 
spi-cilic.it ion  and.  more  fundamentally,  selecting  verification-oriented 
subsets  of  Ada  to  use.  These  subsets  are  discussed  iu  more  detail  lie- 
low . 

Droving  the  roriectness  of  a  program  written  in  a  high  level  language 
in ii si  ,|eai  not  only  with  the  program’s  tlow  of  control,  but  also  with 
its  data  types.  The  above-mentioned  translator  deals  with  control 
Mow.  but  SDVS’s  inference  mechanism  (its  simplifier  and  data  type 
I  lieuiics)  must  deal  with  Ada  data  types.  The  research  issue  here  is 
ht.w  iu  del ei  mine  which  existing  components  of  SDVS  can  be  directly 
.  dapteil  lo  deal  with  Ada  data  types,  and  which  enhancements  to 
s|)VS‘s  influence  mat  hiliery  must  lie  made. 

3.1.2  implementation  Issues 

l  ie-  two  prim  ipal  implementation  issues  that  must  be  addressed  are 
1 1 )  the  construction  of  a  translator  from  our  verification  oriented  sub¬ 
sets  of  Ada  to  state  deltas  and  (2)  the  incorporation  of  Ada-specific 
enhiiliceii’iuits  into  the  SDVS  simplifier  and  inference  machinery.  We 
will  now  dismiss  these  issues  iu  more  detail. 

I  In-  iiaiislator  that  currently  exists  in  the  SDVS  system  transforms 
ISl’S  programs  into  their  Mate  delta  equivalents,  by  means  of  two 
tninrip.il  components,  first  a  purser  parses  ISl’S  programs  according 
to  a  loiirrete  syntax  and  constructs  corresponding  abstract  syntax 
Dees.  Subsequently,  these  abstract  syntax  trees  are  proressed  by  a 
tinnslniism  pntgrum  that  generates  state  deltas.  The  generation  ol 
-.1  ale  deltas  can  he  done  iu  two  ways:  incrementally,  in  concert  with 
tin-  i.  p  by  step  symbolic  execution  of  the  translated  ISl’S  program, 


or  from  markpoint  lo  markpoint  (where  a  "markpoint’’  is  a  program 
point  marked  by  a  label),  in  which  the  aforementioned  incremental 
translation  steps  that  occur  between  markpoints  are  composed  into 
a  single  equivalent  state  delta. 

The  current  ISPS  translator  evolved  in  an  ad  hoc  manner  over  a 
period  of  several  years  into  its  present  form.  In  order  to  document 
better  the  existing  translator,  as  well  as  to  establish  a  systematic 
methodology  for  defining  and  implementing  translators  from  other 
languages  to  state  deltas,  a  formal  description  of  the  current  ISPS 
translator  was  written  (8).  This  formal  description  was  intended  to 
be  both  a  reasonably  precise  specification  and  one  that  would  be  a 
guide  lo  the  implementor.  The  former  goal  was  certainly  met  by 
the  specification,  but  whether  the  latter  goal  was  met  has  yet  to 
lie  ascertained  by  the  actual  construction  of  a  translator  under  the 
guidance  of  the  specification.  We  are  convinced  that  such  translator 
specifications  lead  to  the  production  of  well-documented,  correct, 
and  easily  maintained  translators. 

3.2  Incremental  Development 

The  process  of  adapting  SDVS  to  the  verification  of  Ada  programs 
will  be  done  incrementally.  The  stages  of  development  will  be  keyed 
to  the  identification  of  Ada  language  subsets  of  increasing  seman¬ 
tic  complexity!  each  stage  will  require  the  implementation  of  cor¬ 
responding  rn liabilities  iu  the  Ada-tostate-dolta  translator  and  the 
SDVS  simplifier  and  inference  machinery. 

3.2.1  Ada  Language  Subsets 

Rather  than  trying  to  deal  all  at  once  with  a  full  verification-oriented 
subset  of  Ada,  it  is  more  appropriate  to  proceed  by  degrees  by  select¬ 
ing  increasingly  complex  Ada  language  subsets  to  incorporate  into 
SDVS.  This  incremental  approach  will  lead  to  a  more  orderly  adap¬ 
tation  of  .SDVS  lo  a  new  programming  language.  Our  preliminary 
hierarchy  of  Ada  subsets  consists  of  the  following: 

Core  Ada:  Core  Ada  is  a  subset  of  Ada  intended  to  facilitate  the 
initial  adaptation  of  SDVS  to  Ada.  This  core  language  will 
consist  of  assignment  statements  and  simple  expression  evalua¬ 
tion;  straight-line  program  How;  branching  (if,  case),  iteration 
(loop),  and  escape  (exit)  statements;  simple  input  and  output 
(via  the  0 KT  ami  PUT  procedures);  block  structure,  scoping, 
and  variable  declarations;  simple  packages  containing  only  vari¬ 
able  declarations  and  other  simple  packages;  use  clauses;  and 
basic  datatypes  (integer,  boolean,  array). 

Stage  1  Ada:  This  next  layer  adds  subprogram  declarations,  sub¬ 
program  calls,  and  record  and  enumeration  data  types  to  Core 
Ada. 

Stage  2  Adn:  Next  added  are  user-defined  data  types,  and  some 
higher-level  data  types  from  the  set  (characters,  strings,  fixed- 
point  numbers,  floating-point  numbers,  access  types  (pointers)} 

Stage  3  Adn:  This  final  layer  added  to  the  Ada  subsets  includes 
advanced  features  that  will  require  considerable  research.  In¬ 
cluded  are  exception  handling,  overloading,  generics,  real-time 
features,  and  tasking. 

This  identification  of  Ada  subsets  is  preliminary.  Cote  Ada  and  Stage 
1  Ada  [lose  no  serious  technical  obstacles  that  would  prevent  them 
from  being  interfaced  with  SDVS;  the  required  technology  is  mature 
and  well  known.  In  Stage  2  Ada,  access  types  (typed  pointers)  pose 
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tin*  greater  technical  challenge:.  Pointers  create  problems  with  alias - 
intj  (appmcntly  distinct  names  that  nevertheless  identify  the  sain*' 
object),  but  some  research  has  been  done  on  how  to  verify  programs 
that  contain  Pascal  pointers  [9j.  Finally,  Stag"  3  Ada  constitutes  a 
set  of  research  topics,  as  it  is  not  presently  clear  how  to  interface 
these  Ada  language  features  to  SDVS.  As  our  research  progresses, 
the  difficulty  inherent  in  adding  certain  features  will  become  more 
apparent,  particularly  in  Stage  3  Ada.  Determining  when  enough 
Ada  language  features  have  been  incorporated  into  SDVS  depends 
upon  how  difficult  it  is  to  include  them  and  also  upon  how  difficult 
it  is  to  prove  the  correctness  of  programs  that  use  those  features. 

3.2.2  SDVS  Inference  Machinery 

Only  modest  modifications  of  and  additions  to  the  SDVS  inference 
machinery  are  required  to  accommodate  Core  Ada.  Most  of  these  af¬ 
ter!  the  simplifier.  Core  Ada  data  types  are  intajer,  boolean,  and  one- 
dimensional  arrays  of  these  types.  Explicit  declarations  of  these  types 
must  be  introduced;  currently  only  bit  stritui  declarations  (ISPS*s 
only  data  type)  exist  in  the  system.  The  SDVS  simplifier  already 
contains  most  of  the  logical  axiomat nation  relevant  to  these  data 
types.  For  boolean*,  knowledge  must  bo  added  about  the  xor  (ex¬ 
clusive  or)  operator  and  about  Ada's  ordering  on  the  boolean*  (in 
which  false  <  true).  For  integers,  knowledge  must  be  added  about 
the  operators  /,  mod,  rent,  and  abs.  The  SDVS  simplifier  already 
knows  about  one-dimensional  arrays  having  a  lower  bound  of  zero; 
arrays  having  at  biliary  lower  bounds  must  also  be  accommodated. 
Finally,  a  mechanism  for  dealing  with  the  scoping  inherent  in  block 
'Intel lire  must  be  added  to  SDVS.  The  unique  qualification  of  place 
mimes  (mentioned  later)  is  a  part  of  the  solution.  The  technique 
of  using  existential  quantification  of  SDs  to  control  the  set  of  active 
places,  recently  suggested  by  our  colleague  Tim  Uedmond,  completes 
i lie  solution  of  this  problem. 


4  Overview  of  Coro  Ada 

1  ore  Ada  is  a  simple,  but  nontrivial,  subset  of  Ada.  (  ore  Ada  is 
intended  to  be  the  basis  of  a  rapid  initial  adaptation  of  SDVS  Lo  Ada. 
providing  early  confirmation  *»f  two  technically  sound  but  untested 
techniques:  formal  (Ada)  translator  specification  and  specification- 
diierted  translator  implementation. 

*1.1  Core  Ada  Language  Features 

A  more  detailed  description  of  Cure  Ada  language  features  now  fol¬ 
lows.  These  features  are  partitioned  into  four  groups;  statements, 
expulsions,  declarations,  and  data  types. 

Statements 

Cote  Ada  statements  constitute  a  ••structured  flowchart’'  program¬ 
ming  language.  The  kinds  of  statements  included  are  null,  assign¬ 
ment,  conditional  (if),  case,  loop  (while  loops  with  and  without 
a  condition),  block,  exit,  and  simple  input  and  output  (GET  and 
ITT). 

Coro  Ada  assignment  .statements  can  perform  only  scalar  assign¬ 
ments;  the  left  part  of  the  assignment  must  represent  a  scalar  ref¬ 
erence  (it  cannot  be  the  name  of  an  array).  The  exit  statement 
puividos  a  mechanism  to  esc  ape  from  the  body  of  a  loop  statement 
(especially  from  an  infinite  loop  (one  without  a  condition)).  An  exit 
statement  can  optionally  name  the  loop  from  which  it  escapes,  and 


can  also  optionally  have  a  condition  that  must  hold  in  order  for  the 
escape  to  occur,  Simple  input  and  output,  via  the  text  I/O  proce¬ 
dures  GET  and  PUT,  arc  included  in  Core  Ada  to  provide  a  means 
v_f  formally  specifying  data  input  to,  and  output  from.  Core  Ada 
programs.  Standard  input  and  output  files  are  predeclarcd  for  this 
purpose.  GET  and  PUT  only  input  and  output  scalar  values;  in¬ 
putting  and  outputting  arrays  require  loops. 

Expressions 

A  representative  class  of  Ada  expressions  is  included  in  Core  Ada. 
Those  expressions  contain  numeric  and  boolean  constants;  simple 
names  (identifiers):  compound  names  (e.g.,  pkgl.pkg2.obj);  array 
references  (e.g.,  namo(expr),  where  name  is  a  simple  or  compound 
name  uiul  expr  is  an  expression);  short-circuit  boolean  operators 
(ntid  then;  or  else);  relational  operators  (=,  /=,  <,  <^,  >,  >  =  ); 
binary  boolean  and  arithmetic  operators  (and,  or,  xor,  +  , 
mod,  rem,  +  +  ):  and  unary  arithmetic  and  boolean  operators  (+, 
abs,  not).  Compound  names  permit  in  Core  Ada  the  concept  of 
accessing  items  that  are  not  directly  visible. 

Declarations 

Core  Ada  includes  declarations  of  objects  that  can  be  scalar  and 
oiie-diiiieusioual  array  constants  and  variables.  Also  included  arc 
package  specifications  and  use  clauses  (the  package  specilicalions 
themselves  can  contain  object  declarations,  use  clauses,  and  other 
package  specifications).  These  package  specifications  and  use  clauses 
are  included  in  Gore  Ada  to  represent  a  simple  Ada  encapsulation 
mechanism. 

Data  Types 

Core  Ada  includes  only  very  basic  data  types:  integers,  booleaus, 
ime.djmensionnl  arrays  of  integers,  and  one-dimensional  arrays  of 
boolean*. 


5  Constructing  the  SDVS  Ada  Translators 

'flie  construction  of  translators  from  tin  \da  subsets  into  state  deltas 
will  start  from  scratch  (i.e.,  the  existing  ISPS  translator  will  not  he 
modified  and  used),  and  will  include  both  formal  specification  and 
implementation,  Ideally,  a  complete  formal  specification  would  first 
be  written  to  guide  subsequent  implementation.  Realistically,  most 
of  the  formal  specification  would  be  written  first,  implementation 
would  proceed,  and  then  specification  and  implementation  would  in- 
icr.id  until  they  si  t  m  to  correspond.  The  formal  specification,  ac¬ 
companied  by  textual  explanation,  serves  as  an  indispensable  part  of 
lie  translator  documentation. 

The  Ada  subset  translator  specific <ii ions  will  be  written  by  means 
of  the  technique  used  to  write  the  formal  specification  of  the  ISPfj 
translator  |8).  The  translators  will  be  organized  in  the  same  way: 

Parsing:  A  concrete  syntax  will  be  written  for  each  subset,  and  an 
abstract  syntax  tree  for  each  program  will  be  produced  during 
the  concrete  parsing  of  that  program.  We  use  our  own  powerful 
tools  to  specify  and  implement  this  process, 

Static  Checking:  This  first  phase  of  semantic  analysis,  called  Phase 
1,  detects  “static”  errors  such  its  items  undeclared  before  their 
use,  inappropriate  types,  and  semantically  ill- formed  constructs. 
Provided  that  no  errors  occur  in  Phase  1,  an  environment  for 
the  final  phase  of  the  translator  will  be  produced. 

Translation:  This  final  phase  of  semantic  analysis,  called  Phase  2, 
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incrementally  generates  state  deltas  that  cany  out  the  symbolic 
execution  of  the  sub  ject  Ada  program. 

Other  techniques  must  be  carried  over  from  the  ISPS  experience,  such 
as  qualifying  the  same  identifier  used  in  different  scopes  in  order  to 
make  their  instances  unique  when  they  appear  in  state  deltas  (which 
have  no  scopes). 

The  presence  of  recursive  subprograms  in  Ada  presents  a  new  chal¬ 
lenge.  Recursive  functions  were  not  allowed  in  ISPS;  ISPS  programs 
were,  in  ell’ort,  block-structured  flowchart  programs.  The  SDVS  sys¬ 
tem  maintained  a  map  of  the  association  of  places  with  their  values, 
and  this  map  might  have  been  updated  each  time  a  state  delta  was 
applied.  With  the  introduction  of  recursion,  new  instances  of  places 
local  to  a  subprogram  must  he  created,  or  the  association  maintained 
by  tlu*  place- to* value  map  must  bo  made  more  complex. 

5.1  Translator  Specification 

The  formal  specification  of  both  phases  of  the  SDVS  Ada  translators 
is  written  in  n  continuation-style  denotut ional  semantics  [10].  He* 
cause  of  space  limitations,  the  following  descriptions  are  necessarily 
simplified  and  sketchy;  full  details  will  appear  in  a  forthcoming  tech¬ 
nical  report  [-1] .  It  is  assumed  that  the  reader  has  some  familiarity 
with  tin4  principal  concepts  of  denotatioual  semantics  as  presented 
in.  say,  { It)]. 

1’ha.se  1  collects  the  environment  of  an  entire  program  tor  subsequent 
use  by  Phase  2.  Since  Ada  has  scope  and  visibility  rules  similar  to 
those  of  Algol  and  Pascal,  only  part  ot  this  environment  is  visible  at 
a  given  point  in  a  program,  Consequently,  the  environment  must  be 
fnt  -stntehm  </,  and  access  to  its  components  must  be  appropriately 
mat  lolled  dining  Phase  2.  The  local  environments  of  nonoverlap 
ping  blocks  are  made  to  lie  on  dill'emit  paths  of  the  tree- structured 
environment.  If  the  name  identifier  is  declared  in  I  wo  blocks,  then 
the.se  i  wo  instances  of  the  Millie  identifier  can  be  distinguished  by  flu* 
paths  leading  to  their  respective  local  environments.  Moreover,  these 
identifiers  can  be  uniqiuly  ijtudijird  by  being  prefixed  with  a  textual 
^presentation  of  the  paths  leading  to  their  local  environments.  This 
technique  is  indeed  necessary  when  the  identifiers  appear  in  state 
deltas  in  Phase  2.  as  slate  deltas  have  no  mechanism  to  control  the 
visibility  of  names, 

Tout inuut ions  are  used  in  Phase  1  of  the  Core  Ada  translator  in  a 
very  straightforward  way.  They  simply  sequence  the  static  check¬ 
ing  functions  fi otn  one  program  element  to  the  next,  until  the  entire 
program  lias  been  checked.  If  a  static  checking  error  occurs,  then 
an  nn or  message  is  produced  and  Phase  1  terminates.  In  Phase  '2, 
however,  continuations  are  used  in  a  more  explicit  and  sophisticated 
way.  ( 'out  in  nations  must  appear  in  the  postconditions  ot  state  deltas 
mi  (hat  when  a  stale  delta  i.s  applied,  more  state  deltas  are  generated 
in  order  that  (heir  subsequent  application  can  advance  symbolic  pro- 
giam  execution,  Continuations  are  also  stacked  to  control  explicitly 
the  orderly  completion  of  nested  systems  of  loops  ami  blocks.  The 
initiation  of  Phase  2  of  the  Core  Ada  translation  assumes  that  a  pro¬ 
gram  has  first  successfully  passed  Phase  1,  In  fact,  Phase  '2  can  be 
used  as  the  continual  ion  for  Phase  1. 


5.2  Translator  Implementation 

The  SDVS  Ada  translators  are  implemented  in  Common  Lisp.  The 
translator  specifications  are  written  in  a  style  intended  to  facilitate 
a  straightforward  manual  translation  into  a  corresponding  Common 
l.isp  program.  We  have  adhered  to  this  strategy  quite  faithfully  in 


our  implementation  of  the  Core  Ada  translator,  which  we  now  briefly 
describe.  Full  details  will  appear  in  a  forthcoming  technical  report 

ini. 

The  Common  Lisp  implementation  of  denotatioual  translator  speci¬ 
fications  involves  the  implementation  of  only  two  objects,  semantic 
functions  ami  data  structures.  For  Core  Ada,  two  main  Common 
Lisp  functions  are  defined,  one  for  each  of  the  two  phases.  The  name 
or  each  such  function  is  used  to  prefix  the  names  of  the  remainder  of 
the  functions  defined  in  that  phase.  Common  Lisp  data  structures 
are  defined  for  each  of  the  specification's  data  structures,  and  addi¬ 
tional  data  structures  are  defined  for  subtrees  of  Core  Ada  abstract 
syntax  trees. 

To  oiled  a  transparent  implementation  of  the  (’ore  Ada  translator, 
the  names  of  the  Common  Lisp  functions  are  chosen  to  correspond 
with  those  of  the  denotatioual  semantic  functions,  with  a  prefix  to 
indicate  whether  the  function  is  from  Phase  1  or  2.  For  each  semantic 
function  operating  on  a  single  syntactic  class,  a  Common  Lisp  func¬ 
tion  is  defined  to  handle  arbitrary  syntactic  objects  in  that  class, 
with  subordinate  functions  (whose  names  are  appropriately  an  (fixed) 
defined  to  handle  the  semantic  equations  for  specific  syntactic  cases. 
If  the  objects  of  the  syntactic  class  can  appear  in  sequences,  an  ad¬ 
ditional  Common  Lisp  function  is  defined  to  implement  the  senianlic 
function  for  sequences.  The  bodies  of  the  Common  Lisp  functions 
are  for  the  most  part  obtained  via  direct  transformations  of  the  cor 
responding  semantic  equations.  'These  tiniisfoimations  from  the  do 
Mutational  to  the  Common  Lisp  style  are  detailed  in  [II].  Some 
t  runs  forma  l  ions  that  are  nol  so  direct,  such  as  the  represent  at  ion  of 
continual  ions  by  functions  and  the  treatment  of  the  ellipsis  notation, 
are  justified  in  1 1  ij. 

The  translator  implementor  has  mure  freedom  in  the  choice  of  Com¬ 
mon  Lisp  data  structures  l him  in  1  lie  choice  of  Common  Lisp  function 
definitions;  the  Common  Lisp  functions  must  correspond  more  or  less 
directly  to  their  counierpurls  in  ill"  specification,  whereas  tin4  data 
structures  may  be  chosen  for  maximum  elliriency.  Operators  defined 
on  the  translator  specification’s  data  structures,  however,  are  imple¬ 
mented  by  Common  Lisp  functions  that  are  functionally  equivalent 
lo  the  corresponding  operators,  and  whose  name*;  are  derived  from 
I  he  operator  names. 

5.3  Coro  Ada  Achievements 

1  Muses  1  am)  2  ol  the  Core  Ada  fraii*ln(or  have  been  completely 
specified ,  fully  implemented,  and  Mircehslully  tested.  The  implenien 
t  si  I  ion  of  several  Core  Ada  language  lea  lines  was  tested  by  symbol!, 
vally  executing  the  operation  of  programs  containing  those  fea lines 
on  connote  input  data.  Our  approach  u>  translator  must  ruction 
using  denotatioual  specifications  that  are  uipidhj  translated  into  a 
Common  l.isp  implementation,  has  been  very  successful.  The  Core 
Ada  translator  was  produced  quickly  and  its  checkout  required  a 
minimum  of  debugging  effort  because  of  the  close  correspondence 
between  specification  and  implementation.  When  errors  occurred, 
their  cause  (usually  a  minor  bug  in  the  specification,  the  correspond 
ing  part  of  the  implementation,  or  but  h )  was  quickly  determined  and 
corrected.  As  a  result,  the  Core  Ada  translator  is  well  documented 
and  very  reliable. 

Addition!!  to  the  SDVS  inference  machinery  required  by  Core  Ada  are 
complete  and  have  been  successlully  tested.  Using  these  additions  to 
SDVS.  several  (’ore  Ada  programs  have  been  proved  totally  correct 
with  respect  to  input  and  output  specifications.  Additional  experi¬ 
ence  will  be  gained  by  performing  more  proofs,  It  was  our  colleague 
Tim  Redmond  who  suggested  that  the  semantics  of  loop  statements 
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be  expressed  as  recursive  formulas;  this  suggestion  has  been  incorpo¬ 
rated  into  the  Core  Ada  translator.  Corresponding  proof  strategics 
based  on  fixed-point  induction  are  being  investigated  [12]. 


6  Conclusions 

Through  the  language  Core  Ada,  d  modest  amount  of  Ada  program 
verification  capability  has  been  successfully  added  to  the  State  Delta 
Verification  System  (SDVS).  Research  into  the  application  of  this 
enhanced  capability  of  SDVS  is  ongoing.  Our  next  goal  is  to  specify 
and  implement  Stage  1  Ada,  which  will  add  Ada  subprograms  and 
some  now  data  types  to  the  verification  capabilities  of  SDVS. 

In  our  Core  Ada  experience,  our  strategy  of  first  formally  specify¬ 
ing  a  language  translator  in  the  style  of  denotationad  semantics  and 
then  translating  the  specification  into  a  Common  Lisp  program  has 
been  proven  successful.  The  resulting  Care  Ada  translator  is  well 
documented,  easily  maintained,  and  very  reliable.  YVc  expect  contin¬ 
ued  success  in  the  construction  of  translators  for  more  complex  Ada 
subsets. 

The  generality  and  modularity  of  SDVS  have  shown  it  to  be  quite 
adaptable  to  new  languages  and  verification  applications. 
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Abstract 

This  article  reports  on  the  status  of  the  EHDM  specifica¬ 
tion  and  verification  system,  a  state-of-the  art  environ¬ 
ment  designod  specifically  to  meet  the  noods  of  security 
verification. 

1  Introduction 

The  EHDM  system  is  an  integrated  environment  for  the  de¬ 
velopment  and  analysis  of  formal  specifications  and  abstract 
programs.  It  has  been  under  development  at  SRI’a  Computer 
Science  Laboratory  (CSL)  since  1983,  with  sponsorship  from 
the  National  Computer  Security  Center  (NCSC).  As  its  full 
name  (Enhanced  Hierarchical  Development  Methodology)  sug¬ 
gests,  the  development  has  built  on  SRI's  experience  with,  and 
ideas  from,  previous  system-building  cfTorts,  including  the  orig¬ 
inal  Hierarchical  Development  Methodology  (IIDM)  1 16)  and 
STP  ( 18] .  The  language  of  EllDM  and  the  ElIUM  implemen¬ 
tation  are  quite  different  from  those  earlier  efforts,  however; 
EllDM  incorporates  many  modern  ideas  and  techniques  con¬ 
cerning  language  design,  specifications,  and  development  en¬ 
vironments  in  order  to  provide  a  state-of-the-art  verification 
system. 

1.1  State-of-the- Art  Verification  Systems 

The  capabilities  expected  of  a  statu-of-the-art  specification  and 
verification  system  have  been  summarized  in  the  final  report  of 
the  Verification  Assessment  Study  [10],  sponsored  by  the  Na¬ 
tional  Computer  Security  Center  in  1985.  That  report  describes 
the  kind  of  system  that  could  be  built  with  the  technology  that 
existed  in  1985  and  concludes  that  a  state-of-the-art  verification 
system  should  include: 

1.  A  specification  language  based  on  a  first-order,  typed 
predicate  calculus. 

2.  An  imperative  language  derived  from  the  Pascal/Algol  00 
family  of  programming  languages, 

3.  A  formal  semantic,  characterization  of  the  specification 
and  programming  languages. 

4.  A  verification  condition  generator  (VCG). 

5.  A  mechanical  proof  checker  with  some  automated  proof- 
generation  capabilities. 

6.  A  (small)  supporting  library  of  (reusable)  theorems. 

f  ■  A  glass  (as  opposed  to  hard  copy)  user  interface,  possibly 
using  bit-mapped  displays. 

8.  A  single  system  dedicated  to  one  user  at  a  time  (e.g.,  a 
workstation  dedicated  to  the  verification  process). 


9.  The  embedding  of  these  components  in  a  modest  pro¬ 
gramming  environment  with  utilities  such  as  version  con¬ 
trol. 

The  current  EHDM  environment  matches  these  expectations 
rather  well  and  goes  beyond  them  in  some  important  respects. 

1.  While  the  specification  language  Is  based  on  a  typed  first- 
order  predicate  calculus,  it  also  includes  elements  of  richer 
logics,  such  as  higher-order  logic,  lambda  calculus,  and 
Hoare  logic,  for  greater  expressiveness. 

2.  Although  the  EHDM  environment  does  not  provido  an  im¬ 
perative  programming  language,  it  does  include  a  varioty 
of  constructs  for  expressing  Imperative  behavior;  these 
are  sufficient  for  modeling  simple  imperative  programs  at 
a  level  of  detail  similar  to  Ada  or  Pascal  (see  Section  2.3). 
A  concrete  fink  to  Ada  is  provided  by  a  tool  within  the 
EHDM  environment  that  translates  imperative  code-level 
specifications  from  EHDM  into  executable  Ada  code  (see 
Section  4.3). 

3.  We  are  developing  the  formal  semantics  of  the  EHDM  spec¬ 
ification  language,  as  well  as  a  rigorous  description  of  tile 
operations  implemented  in  the  EHDM  environment,  which 
together  will  provide  a  solid  foundation  for  EHDM.  This 
work  will  be  completed  during  1989, 

4.  The  approach  to  reasoning  about  imperative  features  em¬ 
ployed  in  EllDM  Is  more  general  than  the  traditional  VCG 
paradigm  and  allows  users  to  reason  directly  with  pro¬ 
gram  fragments  (using  Hoare  logic).  So  far,  there  Is  in¬ 
sufficient  experience  with  this  technique  to  determine  how 
it  compares  to  the  VCG  approach  in  practice.  The  equiv¬ 
alent  of  a  VCG  is  available  os  an  additional  tool  for  proof 
development, 

6.  The  prover  component  combines  powerful  heuristics  for 
mechanically  generating  first-order  proofs,  together  with 
decision  procedures  for  standard  theories.  It  supports 
both  automated  proof  generation  and  interactive,  user- 
guided  proof  construction.  Completed  proofs  can  be  cap¬ 
tured  as  proof  declarations  for  inclusion  in  the  specifica¬ 
tion  text  and  subsequent  “replay,” 

6.  The  EHDM  specification  language  incorporates  several  mod¬ 
ern  features  that  support  reusability  of  specifications  and 
proofs.  Specifications  are  structured  into  named  mod¬ 
ules  that  other  modules  can  refer  to.  A  general  form  of 
module  parameterization  supports  generic  specifications; 
this  feature  is  more  expressive  than,  for  example,  generic 
declarations  in  Ada.  The  environment  also  provides  a 
mechanism  for  grouping  standard  modules  in  libraries  of 
reusable  concepts,  theorems,  and  proofs;  such  libraries 
can  be  shared  among  users  and  projects, 

7.  The  standard  user  interface  of  EHDM  uses  the  bit-mapped 
display  of  modern  workstations  and  combines  a  display- 
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oriented  editor  with  multiple  windows.,  menus,  and  mouse 
input. 

8.  The  current  version  of  the  EllDM  environment  is  imple¬ 
mented  in  Common  Lisp  and  runs  on  Symbolics  Lisp 
machines  and  on  Sun  single-user  workstations  and  time- 
shared  computers.  Earlier  versions  of  EllDM  also  exist  for 
mainframes  (Multics,  TOPS-20). 

9.  EHDM  is  implemented  as  an  integrated,  interactive  envi. 
romnent  that  supports  all  activities  involved  in  creating, 
analyzing,  modifying,  managing,  and  documenting  spec¬ 
ification  modules  and  proofs.  An  internal  database  and 
version  control  mechanism  keeps  track  of  the  state  of  indi¬ 
vidual  modules  and  proofs,  and  of  the  interdependencies 
among  modules  and  libraries.  Thus,  KlIDM  is  a  fairly 
complete  development  environment.  However,  since  it 
docs  not  support  a  particular  programming  language  and 
has  no  capabilities  for  compiling  and  executing  programs, 
it  is,  strictly  speaking,  not  a  "programming environment." 

The  KlIDM  environment  provides  additional  IooIk  and  fea¬ 
tures  that  are  not  mentioned  in  the  requirements  list,  but  are 
equally  important: 

•  The  KlIDM  llow  tool  for  analyzing  multilevel  security  (MLS) 
is  based  on  the  noninterference  model  developed  at  SUi  [8, 

7). 

•  KlIDM  supports  hierarchical  structure  and  hierarchical 
development  of  specifications  and  proofs  from  high-level 
requirements  to  code-level  specifications  and  Ada  text 
(which  cun  be  generated  from  code-level  specifications). 


2  The  EHDM  Specification  Language 
and  Logic 

The  KlIDM  specification  language  is  based  on  first-order  typed 
predicate  calculus,  but  includes  elements  of  higher-order  logic, 
lambda  calculus,  and  Mown  logic.  These  enrich  the  expressive 
capability  of  the  language.  Higher-order  terms,  for  example,  are 
convenient  for  expressing  induction  schemas  and  requirement 
statements. 

The  specification  language  is  strongly  typed;  all  entities 
must  be  declared  with  their  type  before  use.  The  type  system 
includes  subtypes  and  function  types.  Specifications  are  written 
as  definitions  and  formulas  (axioms,  theorems,  and  lemmas). 
The  expression  language  includes  all  the  standard  expressions 
of  propositional  calculus,  polymorphic  conditionals,  and  quan¬ 
tified  expressions,  including  quaulificuliun  over  functions. 

2.1  Modules 

Modules  arc  the  basic  building  blocks  of  specifications.  A  mod¬ 
ule  may  represent  the  theory  describing  a  specification  concept, 
an  abstract  data  type,  an  abstract  state  machine,  or  an  (ab¬ 
stract)  program.  Modules  are  closed  scopes  with  explicit  im¬ 
portation  and  exportation  of  names;  modules  can  be  nested. 

Modules  may  he  purameterized  by  types,  constants,  and 
functions.  Semantic  assumptions  or  constraints  on  module  pa¬ 
rameters  can  be  expressed;  these  entail  an  obligation  that  must 
be  justified  for  each  module  instantiation.  This  form  of  mod¬ 
ule  parameterization  is  very  general  and  powerful;  it  supports 


generic  specifications  and  allows  many  complex  constructs  to  be 
built  from  simple  language  primitives.  The  module  inductions 
shown  in  Figure  1  exemplifies  the  use  of  module  parameters, 
assumptions,  and  higher-order  quantification. 

The  language  has  been  designed  so  that  it  naturally  sup¬ 
ports  a  high  degree  of  reusability  of  specifications  and  proofs. 
The  main  vehicle  for  reusability  are  modularization  and  pa¬ 
rameterization  of  modules.  Reusability  is  also  enhanced  by  the 
library  facility  described  later. 


inductions :  MODULE  [don:  TYPE,  first;  don. 

nsxt:  funetionfdom  ->  don]] 


ASSUMING 


dl,  d2:  VAR  don 

nsasurs :  VAR  function  [(loin  ->  nat] 

wollf ounded :  FORMULA 
(EXISTS  meaauro  : 

(FORALL  dl  :  neasure(dl)  <  measure (next (dl ))) ) 

first. ts.firut ;  FORMULA 
HOT  (EXISTS  dl  :  first  -  nsxt(dl)) 

roschsbility:  FORMULA 

dU  /-  first  IMPLIES  (EXISTS  dl  ;  d2  »  next(dl)) 

THEORY 

p:  VAR  functinnldon  ->  bool] 

induction:  AXIOM 
(p(fii'ul)  AND 

(FORALL  dl  :  p(dl)  IMPLIES  pCnoxt(dl)))) 
IMPLIES  (FORALL  d!2  :  p(dS)) 

END  inductions 


Figure  1:  A  1’arnmoterized  Module  with  Assumptions  and 
Second-order  Quantification 


2.2  Hierarchical  Development 

An  important  aspect  of  KlIDM  (and  its  predecessor,  IIDM)  is 
tiie  support  of  hierarchical  development  of  specifications  and 
proofs.  In  a  hierarchical  development,  a  system  module  is  spec¬ 
ified  abstractly  at  one  level  of  the  hierarchy  and  implemented 
using  the  operations  provided  by  the  next-lower  level.  The  idea 
of  structuring  system  designs  in  this  manner  has  been  discussed 
and  used  (in  the  form  of  "abstract  machines”)  since  the  late 
1960s  (cf.  1 14)),  an  early  form  of  associated  proof  techniques 
is  presented  in  (15j.  The  EllDM  language  supports  hierarchi¬ 
cal  structuring  of  specifications  from  requirement  specifications 
through  (usually  several)  levels  of  abstractions  down  to  a  level 
of  code  specifications.  The  links  between  modules  at  adjoining 
levels  of  abstraction  are  established  by  mappings,  which  gen¬ 
eralize  the  notion  of  implementation.  Demonstration  of  cor¬ 
rectness  of  mappings  between  levels  is  supported  by  the  proof 
system.  Tho  traffic  light  example,  developed  in  Appendix  A.l, 
demonstrates  tho  use  of  hierarchical  development  in  ElIDM. 
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2.3  Code-level  Specification 


A  subiangue-ge  is  provided  for  modeling  operational  behavior 
and  imperative  programs,  based  on  the  notions  of  stale  object 
and  operation .  State  objects  correspond  to  “program  variables" 
in  programming  languages.  Operations  express  state  transfor¬ 
mations;  they  have  an  effect  on  state  objects  by  possibly  chang¬ 
ing  their  values.  The  language  also  includes  constructs  for  com¬ 
posing  operation  expressions  that  correspond  to  the  common 
control  structures  of  programming  languages,  The  combina¬ 
tion  of  all  these  features  forms  a  sublanguage  that  is  essentially 
equivalent  to  a  simple  subset  of  the  Ada  programming  language; 
an  example  is  shown  in  Appendix  A. 2.  The  semantics  of  oper¬ 
ations  arc  defined  by  Iloare  formulas,  which  express  properties 
of  the  states  before  and  after  the  state  transformation  denoted 
by  tlie  operation. 

3  The  Theorem  Prover  of  EHDM 

The  thcorom-prover  component  of  Id  1 1  DM  combines  powerful 
heuristics  for  mechanically  generating  proofs  in  first-order  pred¬ 
icate  logic  with  efficient  decision  procedures  for  the  combination 
of  the  following  standard  theories  |19|: 

•  Ground  formulas  in  propositional  calculus 

•  Equality  over  uniiiterprelod  function  symbols 

•  l’rcsburgcr  arithmetic,  i.c,,  linear  arithmetic  will)  the  usual 
ordering  relations. 

l’roofs  (more  precisely,  proof  steps)  lire  declared  In  the  proof 
part  of  a  module;  they  are  expressed  us  a  conclusion  to  lie 
proven  and  a  list  of  formulas  (axioms  and  lemmas)  from  which 
the  conclusion  can  he  deduced.  Proof  declarations  may  also 
specify  ground  terms  to  be  substituted  for  the  free  (technically, 
non-Skolemlzod)  variables  in  formulas.  A  fully-instantialed  proof 
(one  for  which  ull  necessary  substitutions  have  been  provided) 
cun  bo  chocked  for  validity  by  the  ground  decision  procedures 
without  further  input  from  the  user.  An  example  of  such  ii 
proof  (using  the  induction  axiom  from  Figure  1)  is  shown  in 
Figure  2, 


tho.rosult:  PROVE  closed. form  FROM 
induction 

{p  <-  (LAMBDA  z  ->  bool: 

2*aigma(z)  ■  square (z)  iz.) , 
d2  <-  i«C), 

basis, 

inductive. atop  (i  <-  dUPl) 


Figure  2;  A  Fully-Instantiated  Proof 

Proofs  that  are  not  fully  instantiated  can  often  lie  completed 
by  the  high-level  prover  (also  known  ns  the  “instantialor”).  The 
high-level  prover  employs  powerful  heuristics  in  an  attempt  to 
construct  suitable  substitution  instances  Tor  the  formulas  in¬ 
volved;  this  process  can  be  completely  automatic,  or  it  can 
be  performed  in  Interaction  with  the  user.  Completed  proofs 
can  be  captured  in  augmented  proof  declarations  and  included 


in  the  specification  text  for  later  replay  as  fully  instantiated 
proofs.  A  proof-chain  analysis  tool  checks  for  completeness  of 
larger  proof  trees  and  helps  keep  track  of  dependencies. 

Equational  reasoning  similar  to  the  use  of  rewrite  rules  is 
specially  supported  by  the  high-level  proof  procedure.  Tile 
prover  also  implements  the  main  reduction  rules  of  lambda  cal¬ 
culus  and  a  fragment  of  higher-order  logic;  however,  the  char¬ 
acterization  of  tlie  exact  extent  of  this  support  is  still  under 
investigation. 

A  special  procedure  for  reasoning  about  state  transforma¬ 
tions  lias  built-in  knowledge  of  the  meaning  of  Iloare  formu¬ 
las,  state  objects  and  state  transformations.  Tins  procedure 
provides  the  main  support  for  code-level  verification.  It  per¬ 
mits  users  to  reason  directly  with  iloare  formulas,  without 
tlie  traditional  intermediate  step  of  translating  annotated  pro¬ 
grams  into  verification  conditions  (VCs);  the  procedure  also 
supports  reasoning  about  program  fragments,  as  opposed  to 
complete  programs  units  (like  subprograms),  In  these  respects, 
tlie  paradigm  that  is  implemented  by  the  procedure  is  more 
general  than  the  traditional  "verification  condition  generator” 
(VOG)  paradigm.  Ilowevei,  u  tool  equivalent  to  a  VCG  is  avail¬ 
able  in  tlie  10 11  DM  environment  for  use  in  proof  development. 
Examples  of  proofs  with  iloare  formulas  are  included  in  Ap¬ 
pendix  A. 2. 

4  The  EHDM  Environment 

The  EHDM  environment  Is  implemented  ns  an  integrated,  Inter¬ 
active  system  that  supports  all  activities  involved  in  creating, 
analyzing,  modifying,  managing,  and  documenting  specification 
modules  and  proofs.  The  standard  user  interface  of  EHDM  uses 
tlie  bitmap  display  and  combines  a  display-oriented  text  edi¬ 
tor  (customized  and  enhanced  KMAUS)  with  multiple  windows, 
menus,  and  mouse  input.  (A  loss  enhanced  editor-based  inter¬ 
face  is  available  Tor  remote  operation.)  All  operations  can  be 
invoked  directly  from  tlie  editor,  including  the  busic  operations 
of  parsing,  prellypriiiling,  and  typoclieckiug  specilicalion  text, 
invoking  the  theorem  prover,  and  requesting  status  informa¬ 
tion.  In  addition  to  these  basic  operations,  tlie  system  provides 
a  number  of  further  support  tools,  including:  the  MLS  Checker 
(described  in  Section  5),  the  context  uud  library  tools,  the  con¬ 
figuration  control  support,  and  the  EllDM  to  Ada  translator. 

4.1  The  Contoxt  and  Library  Manager 

The  system  maintains  an  internal  database  for  keeping  track  of 
the  state  of  individual  modules  and  proofs  (referred  to  as  the 
workiwj  context)  and  of  the  interdependencies  among  modules 
and  libraries;  the  user  cun  manipulate  this  working  context  or 
switch  between  contexts.  Modules  are  the  basic  entitles  around 
which  the  EHDM  system  is  organized,  and  the  context  feature 
virtually  insulates  the  user  from  the  underlying  file  system.  The 
IOllDM  system  creates  ami  manages  private  files,  which  the  user 
can  ignore  completely  since  all  file  manipulation  happens  as  a 
side  effect  of  user  interaction  with  the  EHDM  system. 

The  library  mechanism  permits  users  to  group  standard 
modules  in  libraries  of  reusable  concepts,  theorems,  and  proofs. 
The  environment  offers  tools  for  creating  and  maintaining  mod¬ 
ule.  libraries  and  supports  sharing  of  libraries  among  users  and 
projects , 

Contexts  and  libraries  have  been  designed  so  that  the  novice 
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user  can  completely  Ignore  these  facilities.  A  user  always  works 
within  a  context,  but  when  a  user  starts  EHDM  for  the  first 
time,  the  system  automatically  establishes  a  working  context; 
later,  when  the  user  leaves  Ehdm,  the  system  saves  the  context 
and  restores  it  when  work  is  resumed.  Users  need  to  know 
about  contexts  only  when  they  want  to  work  in  more  than  one 
context;  similarly,  they  can  Ignore  libraries  until  they  want  to 
make  use  of  that  facility. 

4.2  The  Configuration  Control  Tool 

A  configuration  and  version  control  mechanism  ensures  that 
consistent  versions  of  modules  are  used;  status  checks  report  on 
the  status  of  modules  and  proofs,  and  on  dependencies  among 
modules  and  proofs.  At  any  given  time,  a  module  specification 
may  be  in  one  of  several  states.  When  a  module  Is  typccheckcd 
or  a  proof  performed,  a  “version  check”  is  made  to  see  that  the 
typcchcck  information  (type  tables)  recorded  for  the  transitive 
closure  of  all  referenced  modules  is  still  valid.  For  example, 
If  module  A  uses  module  U,  then  changes  to  module  D  will 
invalidate  the  type  table  for  module  A.  This  Invalidation  will  bo 
discovered  when  module  A  is  acccssad  during  the  typechecking 
of  a  modulo  that  uses  A,  or  during  the  construction  of  a  proof 
from  A  or  a  module  that  uses  A, 

4.3  The  EHDM-to  -Ada  Translator 

Hierarchical  dovolopmont  of  specifications  and  proofs  from  ro- 
qulrcments  down  to  the  code-level  Is  complemented  by  an  ex¬ 
perimental  facility  for  translating  code-level  specifications  or 
“abstract  algorithms"  from  the  EHDM  language  Into  Ada.  The 
EHDM  -to-Ada  translator  has  been  developed  to  investigate  a 
paradigm  of  code  verification  in  which  the  code  written  in  the 
programming  language  is  regarded  as  the  target  of  a  systematic 
development,  In  contrast  to  the  traditional  view  that  regards  it 
as  the  starting  point  of  a  verification  effort. 

The  traditional  approach  is  to  start  with  program  code,  aug¬ 
ment  It  with  annotations  or  “assertions,"  and  attempt  to  deduce 
properties  of  the  code.  Thus,  verification  occurs  after  a  piece 
of  executable  code  has  been  written.  In  contrast  to  the  tradi¬ 
tional  approach,  a  key  Idea  behind  hierarchical  development  as 
embodied  in  EHDM  is  that  actual,  executable  code  Is  the  remit 
of  a  development  process  that  Involves  several  layers  of  abstrac¬ 
tions  and  refinements.  Thus,  the  EHDM  way  to  develop  verified 
programs  is  to  carry  out  tho  necessary  reasoning  at  the  design 
level,  before  actual  program  text  Is  considered.  Tho  advan¬ 
tage  of  this  approach  is  that  most,  if  not  all,  reasoning  is  done 
in  tho  specification  language  rather  than  In  the  programming 
language,  thus  avoiding  the  language  complexities  that  typi¬ 
cally  result  from  design  considerations  such  as  compiler  speed 
or  runtime  efficiency.  Furthermore,  this  approach  leads  to  a 
more  natural  Integration  of  verification  into  the  process  of  soft¬ 
ware  development. 

The  experimental  EHDM-to-Ada  translator  automatically 
extracts  the  “operational  content”  of  an  EHDM  module  and 
translates  it  into  Ada  code  wrapped  In  a  package.  An  example 
of  the  use  of  the  translator  is  shown  In  Appendix  A. 2.  The 
translator  is  baaed  on  a  detailed  comparison  between  the  two 
languages.  In  many  respects,  EHDM  lends  itself  to  translation 
into  Ada,  since  centra!  Ada  constructs  like  packages  and  gener¬ 
ics  have  a  dire't  counterpart  in  the  EHDM  language  (modules 
and  module  parameters).  On  the  other  hand,  the  differences 


between  the  two  languages  are  substantial.  Many  features  of 
Ada  that  are  Important  for  verification  cannot  be  modeled  di¬ 
rectly  in  EHDM.  For  a  tool  based  on  this  paradigm  to  become 
really  practical,  the  specification  language  must  be  much  closer 
to  Ada  than  the  current  EHDM  language;  for  example,  it  must 
take  such  features  as  the  Ada  type  system  and  exceptions  fully 
Into  account. 


5  The  Multilevel  Security  Tool 

EHDM  provides  a  tool  that  analyzes  specifications  for  compli¬ 
ance  with  a  notion  of  multilevel  security  ( M L, S) .  This  MLS  Check, 
er  la  based  on  the  noninterference  model  of  security  (8,7,17)  de¬ 
veloped  by  Goguen  and  Mcscgucr  at  SRI.  This  is  the  main  tool 
In  EllDM  that  Is  specific  to  security  applications. 

Tho  MLB  Checker  examines  certain  types  of  specifications 
and  generates  formulas  (called  verification  conditions ),  which, 
if  true,  establish  that  the  specification  complies  with  the  non¬ 
interference  formulation  of  security.  Tho  verification  conditions 
are  collected  together  In  the  THEORY  section  of  a  new  module 
generated  by  the  MLS  Checker,  and  a  simple  PROVE  or  sc  vor- 
ify  declaration  for  each  verification  condition  is  placed  in  tho 
PROOF  suction  of  the  new  modulo.  Often,  those  mechanically 
generated  I’ROVE  declarations  are  sufficient  to  establish  their 
corresponding  verification  conditions.  If  not,  the  user  must  de¬ 
velop  suitablu  proofs  in  a  separate  modulo:  modifications  to  the 
module  containing  the  verification  conditions  are  not  allowed. 

Thu  verification  conditions  generated  by  the  MLB  Checker 
ensure  that: 

1.  The  result  of  an  operation  depones  only  on  tho  values 
of  objects  whoso  security  classifications  ara  dominated  by 
those  of  the  caller  of  tho  operation 

2.  An  operalloi  (.-'tontially  changes  the  values  of  only  those 
objects  whose  security  classification  dominate  that  of  the 
caller 

3.  Values  assigned  to  an  object  depend  only  on  tho  prior  val¬ 
ues  of  objects  whose  security  classifications  arc  dominuted 
by  that  of  the  object  assigned  to. 

Thcso  three  properties  guarantee  that  a  specification  is  secure 
in  the  sense  that  It  does  not  require  an  unsccure  implementa¬ 
tion;  they  do  not  provo  that  it  wifi  not  allow  an  Insecure  imple¬ 
mentation.  Furthermore,  alnco  security  is  a  negative  property 
(It  is  concerned  with  what  must  not  happen),  a  conventionally 
verified  Implementation  of  a  securo  specification  need  not  be 
securel  The  properties  established  by  the  form  of  flow  analysis 
embodied  In  the  MLS  Checker  are  therefore  quite  limited  and 
should  not  be  mistaken  for  a  “proof  of  security”  |9),  Nonethe¬ 
less,  this  is  a  very  useful  class  of  tool  and  the  only  ono  capable 
of  detecting  covert  storage  channels  [3). 

0  Applications  of  EHDM 

8.1  SEAVIEW 

Currently,  EHDM  is  used  primarily  in  the  SeaVlew  project, 
jointly  conducted  by  SRI  and  Gemini,  which  is  developing  a  de¬ 
sign  for  an  A1  multilevel  secure  database  system  (6,4,5).  In  this 
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project,  a  formal  top-level  specification  of  “secure  distributed 
data  views”  is  being  developed  using  EHDM  as  the  specification 
language, 

This  project  has  considerably  advanced  the  state  of  the  art 
in  multilevel  database  security.  Prior  to  ScaViow  no  demonstra¬ 
bly  viable  approaches  to  multilevel  database  security  existed. 
SeaView’s  approach  combines  element-level  laboling  with  A1 
assurance  -  a  feat  that  was  considered  impossible  as  recently  as 
a  year  ago. 

Among  ScaVicw’s  major  achievements  arc: 

•  A  security  policy  that  defines  what  security  means  for  a 
database  system 

•  An  interpretation  of  the  security  policy  demonstrating 
how  SeaView  applies  the  security  policy  to  a  relational 
database  system 

•  A  multilevel  relational  data  model  that  defines  extensions 
to  the  standard  relational  model  to  specifically  accommo¬ 
date  clement  labels 

•  /.  formal  security  model  that  includes  security  properties 
that  define  secure  state  and  transition  properties  that  fur¬ 
ther  restrict  state  transitions  (to  rule  out  systems  such  as 
“System  Z"  [12]). 

Thu  exercise  of  formally  specifying  the  SeaView  properties 
in  the  KlIDM  language  resulted  in  the  discovery  and  clarification 
of  many  umbiguitics  and  imprecise  or  incomplete  statements  in 
the  original  description  of  the  model.  Through  this  exercise, 
numerous  mistakes  in  the  properties  of  the  model  were  also 
identified  and  corrected. 

0.2  Othor  Application  Areas 

An  early  version  of  thu  EllDM  system  was  used  at  Sill  to  extend 
the  design  verification  for  the  SIFT  fault-tolerant  multiproces¬ 
sor  1 1 3]  previously  carried  out  with  the  STP  system.  This  ef¬ 
fort  involved  the  specification  and  verification  of  rather  subtle 
properties;  the  transcripts  of  the  specification  and  proof  of  the 
system  occupy  more  than  700  pages. 

EllDM  is  currently  also  being  used  to  specify  and  verify  the 
functional  behavior  of  hardware  and  to  formalize  completely 
tlie  published  proof  of  a  clock  synchronization  algorithm  |ll|. 

7  Conclusion 

The  EllDM  system  os  described  here  lias  reached  a  stage  where 
it  cun  support  serious  specification  and  verification  efforts.  How¬ 
ever,  the  development  of  EllDM  is  still  continuing.  We  have 
alroudy  mentioned  the  ongoing  work  on  clarifying  the  formal 
basis  of  KlIDM  ;  both  language  and  system  arc  expected  to  be 
refined  as  a  result. 

The  EllDM  system  is  perceived  by  sonic  as  hard  to  under¬ 
stand  and  difficult  to  use.  We  are  aiming  at  overcoming  these 
difficulties  by  developing  tutorial  materials  that  complement 
the  existing  user  documentation  |'2,lj  and  that  describe  the 
stylus  and  “idioms"  of  specifications  and  proofs  in  EllDM  .  A 
library  of  specification  modules  for  standard  concepts  is  being 
developed  as  EllDM  is  being  used  more  extensively  both  inside 
and  outside  SRI. 


Acknowledgements 

Previous  major  contributors  to  the  EHDM  development  effort 
include  S.  Jefferson,  P.  M,  Melliar-Smith,  R.  Schwartz,  R.  Shostak, 
and  M.  Stickel. 


References 

(lj  EHDM  Specification  and  Verification  System  Version  4-1, 
Preliminary  Definition  of  the  EHDM  Specification  Lan¬ 
guage.  Computer  Science  Laboratory,  SRI  International, 
June  1988. 

(2|  EHDM  Specification  and  Verification  System  Version  4-1, 
User's  Guide.  Computer  Science  Laboratory,  SRI  Interna¬ 
tional,  May  1988. 

[3j  M.  Chchcyl  et  al.  Verifying  security.  Computing  Surveys , 
13(3);279-339,  September  1981. 

('ll  D.  K.  Denning,  T.  F.  Lunt,  P.  G.  Neumann,  11.  It.  Schell, 
M.  Heckman,  and  W.  It.  Shockley.  A  multilevel  relational 
data  model.  In  Proceedings  of  the  1987  IEEE  Symposium 
on  Security  and  Privacy,  1987. 

(6|  D.  E.  Denning,  T.  F.  Lunt,  P.  G.  Neumann,  It.  It.  Schell, 
M.  Heckman,  and  W.  R,  Shockley.  The  SeaView  formal 
Security  Policy  Model.  Technical  Report,  Computer  Sci¬ 
ence  Laboratory,  SRI  International,  1987. 

[G|  D.  E.  Denning,  T.  F.  Lunt,  P.  G.  Neumann,  It.  It.  Schell, 
M.  Heckman,  and  W.  R,  Shockley.  Security  Policy  and 
Interpretation  for  a  Class  Al  Multilevel  Secure  lielalional 
Database  System.  Technical  Report,  Computer  Science 
Laboratory,  SRI  International,  1986. 

(7|  J.A.  Goguen  and  J.  Meseguor.  Inference  control  und  un¬ 
winding.  In  Prnc.  1984  Symposium  on  Security  and  Pri¬ 
vacy,  pages  75-86,  IEEE  Computer  Society,  Oakland,  CA-, 
April  1984. 

[8|  J.A.  Goguen  and  J.  Meseguor.  Security  policies  and  se¬ 
curity  models,  hi  Proc.  1982  Symposium  on  Security  and 
Privacy,  pages  11-20,  IEEE  Computer  Society,  Oakland, 
CA.,  April  1982. 

[9]  Joshua  Guttman.  Information  flow  and  invariance.  In 
Proc.  1987  IEEE  Symposium  on  Security  and  Privacy, 
pages  67-73,  IEEE  Computer  Society,  Oakland,  CA.,  April 
1987, 

(101  Richard  A,  Kemmorer.  Verification  Assessment  Study  Pi¬ 
nal  Report.  Technical  Report  C3-CI101-86,  National  Com¬ 
puter  Security  Center,  Ft.  Meade,  MD.,  1986.  5  Volumes. 

|ll|  L.  Lamport  and  ?.  M.  Melliar-Smith.  Synchronizing  clocks 
in  the  presence  of  faults.  Journal  of  the  ACM,  32(  1)  :52— 78, 
January  1985. 

[12]  John  McLean.  Reasoning  about  security  models.  In  1087 
IEEE  Symposium  on  Security  and  Privacy,  pages  123-131, 
IEEE,  IEEE  Computer  Society  Press,  Washington,  D.C., 
April  1987. 


151 


[13|  L.  Moser,  I’.M.  Melliar-Smitli,  and  R.  Schwartz.  Design 
Verification  of  SIFT.  Contractor  Report  4097,  NASA  Lan¬ 
gley  Research  Center,  Hampton,  VA.,  September  1987. 

[14]  D.  Parnas.  On  a  ‘buzzword’:  hierarchical  structure.  In 
Information  Processing  '71,  pages  336  -339,  IFIP,  1974. 

|15]  L.  Robinson  and  K.  N.  Levitt.  Proof  techniques  for  hi¬ 
erarchically  structured  programs.  Communications  of  the 
ACM ,  20(4):271  283,  April  1977. 

[  16]  L.  Robinson,  K.N.  Lev  it  t,  and  B.A.  Silverbcrg.  The  IIDM 
Handbook.  Computer  Science  Laboratory,  SRI  Interna¬ 
tional,  Monlo  Park,  CA.,  June  1970.  Three  Volumes. 

[|7|  J.M.  Rushby.  The  security  model  of  Kniinncod  1II7M.  In 
Proceedings  7th  DoD/NHS  Computer  Security  Initiative 
Conference,  pages  120  136,  Gaithersburg,  Ml).,  Septem¬ 
ber  1984. 

|18|  R.K.  Shoslak,  H.  Schwartz,  and  I’.M.  Melliar-Smitli.  STP: 
a  mechanized  logic  for  specification  and  verification.  In 
tilh  International  Conference  on  Automated  Deduction 
(CIA  DU-6),  Springer -Vorlag  Lecture  Notes  in  Computer 
Science,  Vol.  138,  1982. 

|lt)|  Robert  B.  Shoslak.  betiding  combinations  of  theories. 
Journal  of  the  ACM,  31(l):l  -12,  January  1984. 

A  Examples 

This  appendix  presents  some  simple  examples  to  demonstrate 
the  features  of  BlIRM  (hat  have  been  described  in  tile  text. 

A.l  Traffic  Light 

The  first  example  demonstrates  the  use  of  hierarchical  specifi¬ 
cation  ami  verification.  We  present  a  very  abstract  characteri¬ 
zation  of  a  safe  intersection  controlled  by  traffic  lights,  a  more 
concrete  realization  of  such  an  intersection,  and  u  proof  that 
tlie  one  is  a  valid  interpretation  of  the  other. 

Tin;  module  colors  introduces  color  as  an  uninterpreted 
type  ami  green,  yellow  and  red  as  constants  of  that  type. 
In  this  elementary  example,  we  do  not  include  the  requirement 
that  these  colors  should  be-  distinct. 

The  module  traffic-light  introduces  the  uninlcrpretcd 
type  intersection,  and  the  constant  initial  of  that  type. 
Eastwest  and  northBouth  are  functions  whose  intuitive  pur¬ 
pose  is  to  return  the  current  color  of  tiie  light  in  their  respective 
directions,  while  change.lights  is  tlie  function  that  changes 
these  colors. 

The  module  saf  e.intersoction  is  a  requirements  state¬ 
ment  for  a  sale  intersection,  it  defines  the  predicate  saf e.lights 
to  bo  true  if  a  rad  light  is  showing  in  at  least  one  of  the 
directions  of  the  intersection,  and  it  requires  that  the  ini¬ 
tial  configuration  of  tlie  intersection  should  be  safe  and  that 
change-lights  should  preserve  safety. 

Thu  modulo  light.eequence  defines  a  particular  sequencing 
of  colors,  while  the  module  pairs  defines  the  theory  of  pairs, 
with  firat  and  second  as  the  selectors,  and  aake.pair  as  the 
constructor.  Doth  these  modules  use  cquational  specifications, 
which  simplify  the  subsequent  proofs. 


Tlie  module  traff ic.light.adt  provides  a  concrete  real¬ 
ization  of  an  intersection  (as  an  Abstract  Data  Type,  or  ADT). 
An  intersection  is  realized  as  a  pair  of  colors,  whose  f  irBt 
component  is  that  showing  in  tlie  eastwest  direction,  and  whose 
second  component  is  that  showing  in  tlie  northsouth  direction. 
The  change. lights  function  provides  a  particular  sequencing 
of  lights  at  an  intersection,  using  the  sequencing  of  colors  de¬ 
fined  by  the  next  function  from  the  light. sequence  module. 

Finally,  the  module  aafe.lights.adt  establishes  a  map 
ping  or  interpretation  from  the  modules  traf f ic.light  and 
safe-intersection  onto  the  more  concrete  traff  ic.light.adt 
A  valid  mapping  requires  that  the  axioms  of  the  higher  level 
modules  become  theorems  of  the  lower  one.  This  is  demon¬ 
strated  in  the  PROOF  section  of  aafe.lights.adt.  Decause 
all  the  relevant  properties  havu  been  defined  cquationally,  the 
high-level  prover  is  able  to  complete  these  proofs  without  fur¬ 
ther  input  from  the  user. 


traffic. light.adt  :  MODULE 

USING  colors,  light. sequonco ,  palm fcolor .color] 
EXPORTING  intersection,  eastwest,  northsouth, 
initial,  change. lights 

THEORY 

intersection:  TYPE  IS  pair 

p:  VAR  intersection 
cornor:  VAR  intersection 

eastwest:  functionlpatr-icolor]  »  first 

northsouth:  function[inr,oruection->color]  ■  uocond 

initial:  intersection  ■  »ake_pair(red ,groon) 
unsafe:  Intersection 

change. lights:  function  [intersection-:*  intersect  ion] 
•  (LAMBDA  cornor  ->  intersection: 

IP  eastwest (corner) -red  THEN 

IF  northsouth(cornnr)*yollow  THEN 
make_pair(noxt(ouHtwest(cornur) ) , 

next (northsouthf cornor ) ) ) 
ELSE  make. pairCusutwust (corner) , 

next (northsouth (corner)) ) 

END 

ELSIF  northeouth(corner)»red  THEN 
IF  oastwest (cornor) -yellow  THEN 

make. pair (next (eastwest (cornor)) , 

next (northBouth (cornor) ) ) 
ELSE  make.pair(next(eastwoBt(coi-nor)) , 
northsouth (corner) ) 

END 

ELSE  unsafe  END  IK) 

END  traff ic.light.adt 
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sal e.lights.adl :  MODULE 

MAPPING  traffic.light ,  saf e.intersection 
ONTO  traffic. light. adt 

THEORY 

trail ic_ light ,  intersection:  TYPE 
IS  trallic.light.adt . intersection 

traffic. light . eastwest : 

funct ion [traf fic .light.adt . intersection->color] 

-  traff ic.light.adt . eastwest 
traf f ic .light . northaouth: 

functionttraff ic.light.adt . intersection- >color] 

-  traffic. light.adt. northaouth 

traf lie. light . initial :  trallic.light.adt . intersection 
■  traf lie. light. adt . initial 

trail ic.light.chongo.lights: 

function [trull ic_ light.adt . intersection 

->  traf fic.light.udt . intorsoctl on] 

•  trallic.light.adt . chango. lights 

PROOF 

USING  light.soquonce,  pairs [color , color] 

WITH  light.soquonce,  pairs 
safo.initially.pr:  PROVE  naf e.initially 
remains. safo.pr:  PROVE  rcmains.safe 
END  sal o. lights. adt 


safo.intornection:  MODULE 

USING  colors,  traf fic. light 
EXPORTING  safe. lights 

THEORY 

corner:  VAR  intersection 

oafo. lights:  functlon[intorsoction  ->  boolean] 
»  (LAMBDA  cornor  ->  booloan: 
eastweet (corner)  -  rod 

OR  northsouth(cornor)  »  rod  ) 

safe. initially:  FORMULA  safe.lightadnitial) 

remains. safe:  FORMULA  safo.lights(cornor) 
IMPLIES  salo_lights(chango_llghta(cornor) ) 

END  aaf e.intersection 


light.soquence :  MODULE 

USING  colors  traf fic. light 
EXPORTING  next 

THEORY 

c:  VAR  color 

next:  function [color->color] 

nl :  AXIOM  next(groen)  ■  yellow 

n2:  AXIOM  next (yellow)  -  red 

n3:  AXIOM  next (red)  ■  green 

END  light. sequence 


pairs:  MODULE[firsttype ,  Becondtypo:  TYPE] 

EXPORTING  pair,  first,  Bocond,  make. pair 
THEORY 

pair;  TYPE 

first:  function  [pair->f irnttypo] 

second:  function  [pair-haecondtype] 

make.pair:  function  [f irattypo , secondtype  ->  pair] 

x:  VAR  firsttype 
y:  VAR  secondtype 
p:  VAR  pair 

radefl:  AXIOM  first(make_pair(x,y))  *  x 
odef2;  AXIOM  second(mako_pair (x , y) )  ■  y 
END  pairs 


traf fic. light:  MODULE 
USING  colors 

EXPORTING  intersection,  eastwest, 
northaouth,  initial,  change.lights 

THEORY 

intersection:  TYPE 
initial:  intersection 

eastwest :  function[intersoction->color] 
northsouth :  function[intorBoction->color] 

change.lights :  function  [  intersect  ion  ^intersection] 

END  traf fic. light 
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bsearch:  operation  tlntArray,  int,  atate[int]] 


colors:  MODULE 

EXPORTING  color,  green,  yellow,  red 
THEORY 

color:  TYPE 

green,  yellow,  red:  color 
END  color 


A.2  Binary  Search 

The  second  example,  the  module  Blnsaarch,  demonstrates  code- 
level  specification  and  proof  by  means  of  a  binary  search  algo¬ 
rithm.  Notice  how  the  text  of  the  algorithm  (the  operation 
bsearch)  is  broken  into  smailer  pieces,  which  facilitates  rea¬ 
soning  about  fragments  of  the  code;  for  example,  the  invariant 
of  the  loop  body  (lemma  Inv)  is  verified  separately  (InvPr)  and 
then  used  in  establishing  the  main  property  (Main), 

The  module  Binaearch  uses  two  other  module  that  are  not 
displayed  here:  IntArrayn  declares  the  tvpe  IntArray,  arrays 
of  integers;  Ordlntervals  introduces  the  predicates  ordered 
and  la. in  on  integer  arrays  and  gives  their  relevant  properties 
in  lemmas  III,  IL2  and  IL3, 


Bineearch:  MODULE  [N :  int]  (*  binary  auarch  module  *) 

USING  IntArraya.  Ordlntervals 
EXPORT  MIG  bsearch 

THEORY 

A  :  VAR  IntArray 

key,  i,  J  :  VAR  Int 

lb,  ub  :  utate[int] 

index,  x  :  VAR  state [int] 

div  :  function  [int ,int->int] 
mean  :  function  [int , int->int] 

■  (lambda  i,J  ->  int:  diY(l+],2)) 

nevindex:  operation 

“»  BEGIN  index  :=  mean(.lb.ub)  END 

newindex.Leml :  LEMMA 

OOlb  AND  lb<ub  newindox  lb<™  index  AND  index<ub 

body:  operation 
"  BEGIN 

nevindex; 

IF  key  >  A (index)  THEN 
lb  :»  index  +  1 
ELSE 

ub  :-  index 
END  IF 

END 


bsform:  FORMULA 

baoarch (A , key , index) 

■  BEGIN 

lb  :-  1; 
ub  :■  N; 

WHILE  lb<ub  LOOP 
body 
END  LODP 
END 

Inv:  LEMMA 

{  ordered (A)  AND  CK-lb  AND  lb<ub  AND 

(is_in(key.A,l ,N)  IMPLIES  is.in(key , A , lb ,ub))  } 
body 

{  0<-lb  AND  lb<«ub  AND 

(is_in(key,A,  1 .11)  IMPLIES  is_in(koy ,A,lb,ub))  } 

Main ;  THEOREM 

{  N>0  AND  ordered (A)  } 
bsearch (A ,  key , index) 

{  lb*ub  AND 

(is_in(key,A,l ,N)  IMPLIES  key-A(lb))  } 

PROOF 

newindex_Lem2:  LEMMA  nevindex  CHANGES  index 
prl2:  VERIFY  newindex_Lom2 
InvPr:  VERIFY  Inv 

FROM  newindox. Loml ,  nevindex.  1.0X2 , 

IL1  (kyC-key,  BOA,  iC-lbSl’l, 
j<-ub®Pl,  k<-indox®Pl) , 

IL.2  (ky<-koy,  B<-A,  i<-lb«Pl, 

]<-ub«Pi,  k<-index«Pl) 

MainPr :  VERIFY  Main 

FROM  bsform ,  Inv , 

IL3  (kyc-koy,  B<-A,  i<-lb«C,  )<-ub®C( 

END  Binsoarch 
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A. 3  Example  of  a  Translation  into  Ada 

The  binary  search  module  also  serves  as  an  example  of  the 
translation  from  EHDM  into  Ada.  The  translation  ignores  the 
Hoare  formulas  and  proof  declarations,  which  do  not  convey 
“operational  content,”  The  function  dlv  has  a  “separate  body” 
since  no  body  has  been  given  for  it.  Note  that  the  operations 
body  and  newindex,  which  merely  denote  code  fragments,  do 
not  appear  in  tho  Ada  text;  they  have  been  expanded  in  the 
loop  body. 


WITH  IntArrays;  USE  IntArrays; 

WITH  Ordlntervals;  USE  Ordlntervale; 


GENERIC 
tl  :  Integer ; 

PACKAGE  B insearch  IS 

PROCEDURE  bsearch  (A  :  IntArray;  key  :  Integer; 

index  :  in  out  Integer) ; 

END  Binsearch; 


PACKAGE  BODY  Binsearch  IS 
lb  :  Integer; 
ub  :  Integer; 

FUNCTION  div  (a_0.  a.l  ;  Integer)  RETURN  Integer 
IS  SEPARATE; 

FUNCTION  mean  (i.  j  ;  Integer)  RETURN  Integer  IS 
BEGIN 

RETURN  div(i  +  j ,  2) ; 


END  mean; 


PROCEDURE  bsaarch  (A  ;  IntArray;  key  :  Integer; 

index  :  in  out  Integer)  IS 


BEGIN 


lb  1, 
ub  N; 

WHILE  lb  <  ub  LOOP 

index  :«  mean (lb,  ub) ; 
IF  key  >  A (index)  THEN 
lb  :»  index  +  1; 

ELSE 

ub  :»  index; 

END  IF; 

END  LOOP; 

END  bsearch; 


END  Binsearch; 
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Ycrifyiii”,  Iiiipk'm<Mit at.ion  Coi'mtncsH  Using 
Tin*  Stall*  Delta  Ycriiio.tiou  System  (SDVS)* 


Ml'l  (  ’lit  ilT 

( 'otiipuli'f  Si  ii'iuo  l.ahnrul ory 
Tin'  AiTOhliac*1  Cor|>nralioii 
I’.  0.  lira  <)-2U.r,T.  M  1/102 
I  .os  Anglos,  CA  !)(][)!)!) 


Abstract 

Tin*  formal  colirepl  ol  implementation  correctness  and  its  embodi¬ 
ment  ill  llit'  Si. ila  Drllit  Veiilicnlion  System  (SDKS)  jut  briellv  de¬ 
scribed.  Described  nn‘  i i n |»t >rl  n 1 1 1  It’itl  ii  res  added  lo  a  prototype  ver- 
>iiin  nf  Sl)\  S  as  a  result  of  experience  wii h  a  substantial  im ploiuon I «i - 
I  ion -i  t utim’I  ness-  verifiea i inn  effort.  Tlit*  result  is  a  usable  version 
of  SDK’S  tlial  ran  In*  applied  lu  increase  confidence  in  micropro 
grammed  computer  iinpIt’iiK’iilal inns;  this  version  is  also  being  ex¬ 
panded  In  \<‘iilv  ilir  implementation  correct ness  ol  programs  and 
hardware  [  I J. 

1  Formal  Computer  Descriptions  and  Verifi¬ 
cation 

A  nmi  pul  at'  sysli'in  design  is  hierarchical:  ihai  is,  descript  inns  *  >1 
I  ho  >>>!.•’ Ill  components  art'  developed  al  different  levels  (algniith 
mi' .  programming,  archil- *1  Mini.  or  It ansfer.  gate,  circuit .  and 
i  ui  t’j.’.a  i<’d  c  i  rrn  i  1  mask)  u.tt  vary  in  (lit*  amouul  of  delnil  they  in 
nii|)o,-;iii>l  T!n*  tools  ii.M’d  in  l In*  design  process  often  imed  a  formal 
desriiption  of  ilu'  design  at  ilm  appropriate  level,  as  the  following 
ill  tisl  i  ;>l  ■*: 

•  A  proiiia in tiling  language  is  used  al  I  hr  programming  level  lo 
specify  I  hr  input  hi  the  cumpilei 

•  A  Boolean  irvrl  descript inn  language  is  mm’iI  to  specify  tin’  in 
pul  in  logic  miiiiiiii/al ion  pinj^iaiiis. 

•  A  genumi iv  oriented  language  i-'  used  lor  each  layer  at  1 1n’ 

aiiul  <  imiit  mask  hivrl  in  spnify  lln*  input  io  llm  pal 
trrji  gejiei a i ■  i| , 

TIm-m*  (nniiid  descripl  ions  aiav  also  h«*  iimmI  hi  verily  tlir  correctness 
ol  t lif’  desiga.i.e.,  Dial  it  is  consistent  with  l hi’  specific;)! imis  of  the 
computer  system.  This  vi'iilu  alioti  process  is  especially  important 
in  \Vstems  lor  which  a  design  error  is  rosily.  Mich  as  in  applications 
in  which  security  is  vital  or  in  spacehorne  applical ions. 

With  most  vrriiif  at  ion  systems,  1  hr  descriptions  ol  a  computer  sys 
trill  air  rewritten  In  llir  designers  or  veriliers  in  tlir  language  n mliT 
lying  l  hr  logic  of  t  hr  'vrilical  ion  .system.  I  *  n  It  »rt  ill  lately.  sprrilical  ioli 
riTOI's  cfri’p  ildo  this  process  ami  t||e|e]iy  increase  tlir  cost  ol  tlir  ver¬ 
ification  rll'ort  ami  reduce  llir  COIilide|i<e  ill  I  hr  irsnlls. 


Mils  research  was  suppol  led  in  part  hy  I  h«*  Aerospace  l  ■  a  pi'i'al  i*>n  and 
in  pari  hy  tlir  National  Computer  Senility  Center  under  cm:!  out  I  till l) I 
N.ri-(  -U()8fi  -  |M1(M)  Ki. 


The  State  Delta  Verification  System  (SDK’S),  developed  in  the  Com¬ 
puter  Science  Laboratory  of  The  Aerospace  Corporation  [2j.  takes 
a  dilleifiii  approach.  Hy  using  the  design  language  rattier  than  Du 
language  of  I  he  verification  system,  SDVS  has  an  intrinsic  advantage 
over  oilier  Verified  I  ion  systems  in  that  it  is  easily  integrated  into  llir 
design  process.  SDK  S  reduces  specification  ennrs  by  translating  the 
designer’s  descriptions  automatical! v  into  slate  deltas,  which  com¬ 
prise  the  underlying  logic  of  l he  SDK’S  system.  Currently,  SDK'S 
suppoiis  portions  of  the  design  languages  ISPS  [*tj  and  Ada  llj. 

The  remainder  of  this  paper  discusses  (I)  the  formal  concept  of  im 
plmnentni ion  correct  ne.ss  as  it  is  embodied  iu  SDK  S.  (2)  how  Si)\  S 
supports  implement  at  ion -correct  ness  proofs,  (d)  how  SDKS  has  been 
applied  to  a  formal  proof,  and  {•!)  how  SDK’S  is  being  enhanced  to 
.support  iiiipleini’iitat  ion-miTcci  ness  pi  oofs  at  multiple  ievols  ol  de¬ 
sign.  These  enhancements  will  lesnll  in  increased  nmlideiice  in  the 
correct  Hess  of  the  design  throughout  the  design  cycle. 

2  Implementation  Correctness  Using  SDVS 

Coil  imI  ness  proofs  al  high  levels  of  design  abstraction  (e.g..  program 
vei  ilica  I  ion )  involve  verifying  the  consistency  of  a  particular  design's 
represent nl ion  with  respect  lo  input  and  did  put  assertions.  As  dis¬ 
cussed  above,  these  assert  ions  are  normally  written  in  ||h*  language 
o|  the  underlying  logic  of  tin*  verification  system.  Impl  'iiuMitat inn- 
correct  nest*  proofs  in  SDK’S  dilfer  from  the  traditional  paradigm  in 
that  they  deal  with  two  representations  (if  |  he  design  at  diMerenl  lev¬ 
els  ol  detail.  The  levels  of  a  list  miction  we  are  considering  for  imple 
mentation  correct  ness  correspond  to  computer  program,  computer 
instruction  set.  computer  microprogram  engine,  and  gale  level  de¬ 
sign.  All  of  I  liese  levels  r  an  he  handled  wii  bin  l  lie  implement;!  t  ion- 
correct  ness  paradigm. 

I  n formally,  one  says  I  lint  a  lower  level  specific ’al  ion  .S'j  ini/i/i  hk  nb1 
a  higher- level  sp”ci  lira  lion  .S'-j  if  the  signilicatil  state  change*  that  .V, 
make.*-  are  also  made  by  .S' (  ( ii.-ually  by  a  sequence  of  more  primitive 
slate  changes).  This  concept  is  very  general  and  can  be  applied  to  any 
pail  o|  levels  o|  l  he  computer-system  hierarchy.  Tim  implementation 
relation  is  not  necessarily  symmetric;  there  may  he  state  changes  of 
.S’|  th.it  have  no  corresponding  signilicnni  stale  changes  in  ,S‘^ 

Phis  informal  notion  of  implement  at  ion  correct  ness  is  brsi  captured 
in  a  formal  mi  redness  theorem.  Because,  in  general,  the  two  de¬ 
scriptions  will  have  dilfeieni  data  st  run  ures  and  inleriial  states,  I  lie 
key  to  the  implement  at  ion -correct  ness  theorem  is  in  provide  the  cor- 
lespoiiiieuce  between  ii |)pei- level  and  lower- level  data  and  state  uni 
verses.  This  correspondence,  called  indjiftinff  in  SDK’S  [(»].  is  tin* 
means  through  which  slate  changes  at  one  level  correspond  Instate 
changes  al  llir  oilier  level. 


1  Si>nii-lim«  .v  i lie  iron  “’.minl.ili-s"  [■'*}  iim  »l  f<»i  wli.il  we  r  .ill  “imptr'iwnis  ; 
ni'Wi-vi’r.  vvr  {»rc|f|  lln-  J.ilti-i  icon  l:r«-;uiJ.i-  I  !»■  luum-i  «  njiimi«-s  a  N’siiuu  in.  ilunl 
i.|i»Ky  ainl  i*  is  |iiiiu.iiilv  u*-»  U  lei  a  s|»»‘i  ife  peiinm  <>f  lln-  <  mii|nj  ha -sysli'in 
hid  .it  iiiy. 
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'I'll  In 'n'm  this  fonmili/aiion  process,  we  Imilci  a  semanlic  base  for 
ruin  pul  <ii  imi  ami  for  Die  implementation  of  one  compulation  by  an* 
ti!ln*r  romput  at  inn.  During  a  mm  put  at  ion.  1  lio  program  variables 
take  on  values  from  the  mniputnlionul  tlnnuiur,  wo  capline  this  con- 
cop  l  formally  below. 

Definition  1  (.4.  (.VP)  is  a  computational  domain  if  ami  only  if 

*  A  >■'  ) limit  I  for  tin  tifjH tl  first -onUr  lunyutnjt  C.  irln  n  C 

turn  /y/*  *  place,  domain.  uml  architecture,  when  flu  ////« 
architecture  n  pn  st  uts  a  Hanhuu  alythra.  C  ronlain s  mint 
of  flu  symbol*  ..  ft.  ■"»-*.  I*,  or  ||  *  )|:  utnl 

•  P  is  a  Jinitt  si  t  of  sluft  nn  nls  from  l(.)  ir/n  r(  “.  "  is  a  f mint  ion 
symbol  fmm  li/jn  place  to  type  domain.  All  iwrurrt  nrt  s  oj 

in  s1  nti  m  is  Jmm  P  an  npplinl  to  constant  plan  symbols  from 
tin  ltn><!uu(/<  C. 

I  lii1  »*iic«'h  in  P  .ire  called  lit rln rations.  The  object*  of  typo  place 
ate  m  <i  nite  to  uiie  coiTc.spnndcm  e  with  I  he  variables  of  the  eonipu 
i ,i ( ii iii  \\i-  ihiiik  <*1  ihe.-e  objects  as  ■-  mg  actual  places  or  register* 
:n  .i  iii.ii  !nn»\  II1  validities  take  oi.  ..dues  that  are  tin*  objects  ol 
tv  pe  domain. 


Hon t;lily  speaking,  iti  the  mapping  of  I.xnmph*  1.  nnr>  can  obtain  l lie 
upper  compiitat  ion  Irohi  the  lower  compulation  by  forget  ling  tin* 
contents  of  the  places  not  in  the  upper  domain. 

The  mapping  comes  into  play  in  different  ways  in  l  lie  i,vo  pads  of 
the  theorem  of  implementation  correctness  [7): 

•  '1*  lie  iti  rla  rot  ions  o\'  I  he  upper-level  variables,  including  at  1  rib  ill  es 
such  as  hiist  ring  Icngi  Ii.  range  of  arrays,  and  disjoint  ness,  must 
he  implied  by  the  declarations  associated  with  the  tonespond- 
ilig  lower- level  variables. 

•  The  .si  mantles  oft  hr  image  of  J  lit'  upper-level  dcM'iipi  ion  under 
ihe  mapping  must  he  implied  In  tin4  semantics  ol  the  lower- 
level  description.  In  SDVS.  the  semantics  ate  defined  by  the 
underlying  logic  of  the  verilication  system. 

Whenever  we  are  discussing  computational  models  ovoi  the  upper 
and  lower  domains,  we  will  use  ,ty"  ~  ,(n"  be  /'**)  and  \t‘  -■ 

<r'.o!  i)  as  the  defaults,  respectively.  We  will  also  i|se  the  slate 
delta  logic  to  describe  the  Inwei  and  uppet  coinpnl at ional  models. 
We  will  use  TT1'  (  tt  / )  to  represent  sets  of  sentences  from  tin*  uppet 
(lower)  logic. 

:\\>w  we  are  ready  to  deline  jormulh  tin*  notion  ol  implementation. 


Definition  2  i  I  Ao,]tl  t)  a  computational  modol  on  r  a  ram- 
/m hit •mial  itomaiu  \A.i'.P\  if  *nnt  only  if 

>  t  n  Inna  ily  on!,  ml  sit  with  a  iiimnnui  •  It  mint,  ami 

•  tor  no  hi  i  1  .  ■ r ,  i.%  a  function  from  flit  ih  nn  ills  of  A  oj  typi 
place  to  tin  ,  h  n. i  nis  of ,  [  of  ri//«  domain. 

I  i-i.dl.-d  the  1  melino  o|  t  lie  computational  model.  !»»•  au\  /  c  i  . 
a.  ,*  •  .db  d  .i  in  I  lie  i  ompiltiit  mil. 

I  in  ap\  /  .  I  and  anv  « >l» i»M  l  /•  id  tvpe  place  in  C.  the  ‘contynts 
■•t  /■  .»  time  "  1  «‘|e|  s  to  I  lie  \a|lie  ol 

I  he  Inlli i\\i lie.  definitions  make  lolliial  wh.it  we  ire-.m  hv  an  install*  e 
•*l  a  InWi'l  level  IU.kIiIII"  implementing  all  Upper  l»'\e!  ||  l  ,i«  III  Ilf. 

Delinit  ioii  . U  A I  n  mapping  model  from  tin  *#/»/»»•  »/»- 

n,n-'r  |.  \  .  i'  i  in  lilt  lom  i  iliiltnnn  { A*  L  ‘  I  if  ttial  only  if 

•  W  ,r,„/A:  tin  •  otiipnlolnnnil  iamb  Is  on  r  tin  loin  i  t.ml  upjy  i 
i/iiim/o;-.  n  ->p,  if  oily.  an  1 

•  tin  him  I;  at  of  A  !  '  <  '  a  'iili'-t  t  of  till  hint  Ilia  »■/  A  l 


Definition  *1  implements  n”  irith  n  spirt  to  tin  nnippmy  p.  ih 

nuh  il  by 


iff Jor  tiny  (At1.  Af1' )  in  ft  out  has 

[AC  h  -  (.H“  |-  r" j 

rn.ni  [ T J .  we  know  that  implementation  satisfies  ndlexiviiv  (with 
respect  to  f lie  ideul it y  mapping,  any  sentence  implements  itself)  and 
transitivity  (il  pi  t  .Ti  4  ••  and  //.»  I-  t  *  ,7<  then  // 1  !  «i  •  •  rr.o 
whrie//,  is  I  he  relational  min  posit  ion  of/ft  and  p-.) 

S I ) \‘S  takes  a>  input  Jdrm.il  descriptions  of  l  lie  lower  level,  the  up 
per  level,  and  tie*  mapping  fundioii.  and  aiitonial  i<  ally  ne.ites  .m 
im|ib‘menlation  coiiedness  theoiein  in  the  underlying  mat  lu-mat  i 
c.il  logic  of  SDN'S.  I  hi-  theoM'lll  rep  resell  Is  1  lie  claim  that  the  lower 
level  implemeili  -  I  li«»  uppei  level  via  tile  mapping.  Ilw4  «  (Mil  Itiatid 
that  does  this  work  i-  called  iniph  nit  nfahon;  \)  euc.i[>sulates  the  lac  1 
that,  under  the  light  restrictions  on  the  mapping,  a  proof  ol  im 
piemen  t  at  inn  can  be  canied  out  entiielv  in  the  lowei  bvel  i.mgtmge 
ami  |ogi«  .  I  hi-  new  command  embodies  fi  more  geneial  ami  foniial 
mapping  delinit  ion  than  that  tise»|  in  previous  veision-  u|  t  h>- -v  -lem 

I'4].  II. IV  illg  I  he4  1 1 . 1  pi  • 1 1 1 M  *1 1 1  of  il  Ml  tlieolelll  ill!  I'hIuccmI  1 » V  t  lie  s\  •lein 
latliei  1  ii  a  ii  1»\  I  lie  1 1  se  i  lead*,  in  more  teii.ibb1  pn»>‘|s,  .n,d  nn.gllie 
nioie  genei al  mapping  leads  to  hroadet  appiii  ahilit v. 


I  mapping  h  . . in  appi  r  Aoinam  l  „*l'' ,(')/"«  loir  ■  r  •tnuniin  ( .-l- .  L  !  ' 

</  sit  o]  miififOiiii  ninth  is  luhri.n  thost  saint  t  Ioniums. 


lixamph*  1  liu/i/in'f  that  tlx  upfu  r  ilotinun  anti  tin  hurt  i  tlonioni 
,1,1!,  ,  mily  m  that  It,,  p’art  -  in  Ur  nppt  r  moth  l  A'"  nn  a  >nh*.  /  oj 
th,  p/mix  n,  th,  loin  i  moth  l  A"  lion  that  is  a  iniyfo  nnippmy 
i  otisi'Ulni  ,1/  iiiilp/ina/  ninth  P 


that  -fi/i4/ v 


</■/;»  n  P  #s  tin 


«(/  /=).</ '■*{'Trb.  / -)  1 

r  r' 

'J I  I  I  ‘o]‘  rr:|/v' 

-i  /  oj  nh/.rls  m  of  lyjit  place 


< )  i  lmr  vej  ilic  at  ion  sv  si  i>nis  also  deal  With  t  In4  issue  o|  o  >i  t  «‘spoiich*n>  e 
lietvvceu  level*..  Idrexampl".  in  I  DM.  iua  .lo  pioduc<*s  ,i  llienieju 
oi  implementation  based  on  a  mapping  in  a  manner  simiiai  to  that 
Used  !)\  s|)\  S;  see  J‘t]  loi  ail  illforin.il  ile-i  i  iption 

I'lgure  |  ilbi'-t  i  ate-  how  J>|)VS  in1«*ila«es  in  the  i  m  jileiii.  at  a  ■  ion 
eoi|ectm*ss  plocess.  These4  element  s  ate  divinssed  blie!|\  In  I  lie  fol 
lowing  sec  i  ions. 


2.1  State  Dellas 

SDNS  cheeks  ptools  ol  stale  deltas  [ittj.  1  oi  example.  SDNS  «  an 
handle  proofs  ol  Haims  ol  ilie  lorin  "if  1’  is  trie  now.  tint.  vvill 
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2.3  Proving  the  Theorem  of  Implementation 


Figure  1:  Implement  at  iun-('urter\  ucss  Verification  as  Performed  by 
SDVS.  The  »ser  provides  the  l wo  ISPS  descriptions  and  “TH”  trans¬ 
lates  thorn  into  state  deltas.  The  user  eons* I  mots  a  mapping  from 
variables  ami  states  o!  the  upper  level  description  to  variables  and 
stales  of  the  lower-level  description,  SI)\'S  creates  i|ie  implomenta- 
t  ion -correct  ness  theorem  and  the  user  inputs  the  outline  of  l  he  proof, 
which  l lie  system  completes  and  checks  for  validity. 

become  true  in  the  future/*  If  P  is  a  program  (perhaps  with  some 
initial  conditions)  and  Q  is  an  output  condition,  then  tin1  above  claim 
is  an  input-output  assertion  about  P.  SI) VS  can  also  prove  claims  of 
the  fortn  “if  P  is  true  now.  then  Q  is  true  now.’*  In  this  case,  if 
P  i>  a  progrant  and  Q  is  a  rpecificatioii,  then  the  claim  asserts  the 
correctness  of  P  with  respect  to  Q. 

A  computation  (a  sequence  of  state  changes)  is  specified  by  a  state 
delta  or  set  of  state  deltas.  In  order  to  facilitate  compact  descriptions, 
the  user  .specifies  which  variables  change  value  as  the  slate  changes 
from  one  in  which  P  is  true  to  one  in  which  Q  is  true.  Thus,  the  true 
statements  involving  variables  that  do  not  change  will  remain  true 
in  the  new  state.  In  particular,  if  it.  is  specified  that  no  variables  are 
allowed  to  change  as  the  state  changes  from  P  to  Q,  then  Q  must  be 
true  in  the  Mate  satisfying  P.  and  the  meaning  is  simply  the  static 
claim  that  P  implies  Q. 

I  his  discussion  provides  only  an  intuitive  notion  of  state  deltas,  l  or 
a  vigorous-  definition  and  examples,  see  the  SDN’S  user's  manual  [11]. 

2.2  Describing  the  Levels  of  Implementation  to  SDVS 

The  mechanics  of  verifying  implementation  cot  reel  ness  using  SDVS 
involve  the  automated  translation  of  specifications  written  in  a  pro¬ 
gramming  language  to  the  underlying  formal  logic.  Thus,  SDVS  can 
take  as  it. put  the  actual  description  used  by  the  computer  design¬ 
ers.  as  well  as  the  act  mil  program  to  be  executed  on  the  computer. 
Other  systems  require  that  the  description  or  associated  comments  be 
written  in  the  underlying  language  of  the  verification  system.  While 
SDVS  currently  only  accepts  descriptions  written  in  ISPS  [12]  (which 
is  suitable  although  not  ideal  for  microprogram  verification),  we  re¬ 
cently  developed  a  formal  technique  for  specifying  ‘lie  SDVS  tinusja- 
tioii  of  other  languages  [3],  and  are  applying  it  to  programming  and 
hardware-description  languages. 


Because  there  is  no  general  procedure  for  deciding  the  truth  of  the¬ 
orems  in  computer  verification,  many  proof  strategies  are  possible. 
Ail  important  characteristic  of  SDVS  is  that  its  proof  strategy*  is 
a  practical  compromise  between  completely  automated  proofs  and 
completely  manual  proofs.  A  powerful  proof  system  that  requires 
no  guidance  by  the  user  can  waste  a  lot  of  time  trying  approaches 
that  an  experienced  mathematician  would  easily  see  are  inappropri¬ 
ate.  Alternatively,  a  system  that  checks  step-by-step  proofs  input  by 
the  user  executes  very  quickly,  but  the  tedium  of  dealing  with  every 
minor  step  of  the  proof  wastes  the  user's  time.  With  SDVS,  the  user 
provides  a  high-level  proof  strategy,  additional  facts  useful  for  llio 
proof,  and  “hints”  to  aid  the  system  in  specific  proof  steps,  while  the 
system  handles  the  details  of  the  proof  automatically.  This  compro¬ 
mise  strategy  is  also  successfully  used  by  other  formal  proof  systems 
(13][U).  SDVS  makes  this  strategy  particularly  effective  by  allowing 
the  user  to  interact  with  the  system.  The  interface  to  SDVS  was 
significantly  enhanced  in  the  latest  versio  i,  giving  the  system  the 
ability  to  act  as  a  data-base  manager  for  proofs. 

The  proof  language  itself  is  divided  into  sta  ie  and  dynamic  parts 
'l  lie  static  part  deals  with  proving  that  certain  assumptions  imply 
certain  conclusions  about  a  given  state.  The  dynamic  part  controls 
the  stale  transitions  made  by  the  system.  It  includes  constructs  for 
proof  by  symbolic  execution  ( correspond' ng  to  sequent  ial  execution), 
proof  by  ctiM's  (corresponding  to  branching),  and  proof  by  induction 
(corresponding  to  loops),  When  execution  has  arrived  at  a  new  state, 
a  static  proof  may  be  needed  to  verify  that  new  relations  do  in  fact 
hold  (in  order  to  show  that  the  postcondition  is  true  ami  the  goal  is 
reached,  or  to  show  that  a  precondition  is  true  and  a  new  stale  delta 
may  be  applied). 

For  simple  iheo'b's  where  efficient  decision  procedures  exist  and  are 
implemented.  SDVS  derives  all  conclusions  without  any  user-input 
proof.  Examples  of  such  theories  are  equality  over  un interpreted 
function  symbols  and  some  fragments  of  naive  set  theory.  For  more 
complicated  domains,  the  system  allows  the  use':  to  write  proofs  by 
having  the  system  notice  more  and  more  difficult  conclusions,  where 
the  newly  verified  conclusions  arc  saved  and  used  as  lemmas  mi  which 
to  base  the  next  conclusion.  The  derivation  from  a  given  set  of 
lemmas  to  the  next  conclusion  may  be  automatic  in  some  cases,  or 
it  may  require  the  user  to  designate  that  an  axiom  or  a  previously 
proved  lemma  is  to  bo  applied. 

SDN'S  provides  an  abstraction  mechanism  for  combining  a  sequence 
of  state  changes  into  a  single  state  change  [15].  This  is  crucial  lo 
managing  large  proofs.  The  system  may  be  run  in  interactive  mode, 
in  batch  mode,  or  (as  in  most  real  applications)  as  a  combination  of 
the  two.  In  the  interactive  mode  the  user  writes  the  proof  in  SDN’S 
with  help  from  system  prompts,  the  system  executing  each  proof 
command  as  it  is  written.  Expressions  are  written  in  standard  infix 
notation  (e.g.,  x  +//).  In  the  ba*ch  mode  the  proof  is  written  by 
means  of  the  editor  and  is  then  executed  by  SDVS  with  no  further 
user  interaction.  Most  commonly  a  proof  is  written  interactively, 
stored,  and  later  rerun  in  batch  mode. 


3  A  Case  Study 

Although  several  examples  were  developed  and  verified  (o.g.,  [1(5]) 
during  the  development  of  a  prototype  version  of  SDVS.  t ho  first 
significant  application  of  SDVS  was  lire  C/30  Microprogram  Veri¬ 
fication  Project,  begun  in  October  1984.  Tins  project,  ivliirli  was 
completed  in  November  198(3  [17],  used  SDVS  Version  b  to  develop  a 
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formal  correct  ness  proof  of  1  IS  of  the  |‘2S  instructions  (implemented 
by  over  om*  thousand  mi  noin. si  ructions)  in  the  C/HO  repertoire.  Six 
('/:«)  i  list  nut  ions  wort'  fount!  in  have  boon  implemented  incorrectly 
by  t ho  microprogram.  These  errors  wore  confirmed  by  tin*  respon¬ 
sible  engineer  (they  wort1  mr roc ted  in  a  Inter  le  lease  of  l lit-  ('/HO 
microprogram ). 

'l  iit*  (‘/•til.  specifically  designed  1»  serve  as  a  packet  switching  node 
nti  t lit*  Deft1  n si*  Data  Network  (DI)N),  is  out*  of  it  family  of  com¬ 
puters  developed  by  Holt.  Mernnek.  and  Newman  (MHN).  The  (-/MO 
is  a  Ib-hil/woi'd  machim  wiili  (MK  words  of  addressable  memory 
iind  t liree  addressing  modes.  It  lias  a  number  of  special-purpose 
iind  general- purpose  rrgisii  **»  ami  a  sol  of  l*JN  instructions,  includ- 
i ii ii  sojiliislicated  iusl  rm  liwis  for  manipulating  queue  data  structures 
and  coul rollinu  miiltiprc  ■  •  -sing.  It  also  operates  a  polled  inierrupt 
system,  with  Jock.  I/O  md  scheduling  interrupts.  The  ISPS  de¬ 
scription  of  the  t'/.HU  ( .ippi  "\iinately  .'{()  pnges  of  test)  was  based  on 
lln*  reference'  iimipmI  <1  validate!  i lirnii^li  simulation.  Ten  of  tin* 
l‘<?X  i nst in d ions  in  i lie  ran  instruction  set  were  not  considered  for 
verification,  including  ii  true  lions  that  manipulate  (be  1/0  system 
of  :|ie  (  ‘/Hi)  (tlievr  i  u-’ ■  >i<  lions  were  incompletely  documented  and 
1 1n i s  tl i (ficii It  to  '.piMiiv  formally).  As  there  was  not  enough  lime, 
four  oilier  instrui  hoi.  •  were  not  verified. 

TlieC/MO  is  impleiiii-nied  by  a  microprogram  llinl  executes  on  MHN’s 
Micropromnininabl-  building  block  (MHH)  processor  j  is],  ’Hie  C/IU) 
iiiipleiiM’iital ion  was  chosen  for  verification  because  of  an  interest  in 
verifying  certain  nspm  >  •  of  l)l)N.  aild  because  of  the  existence  of  a 
lortmil  ISPS  description  of  a  version  of  tin*  MMB.  This  description 
(coincidentally  also  approximately  HO  pages  nf  text)  was  partially 
in  exist (*ni  e  ,« i  i lie  lime,  and  was  validated  through  simulation  and 
through  discussions  with  MMN. 

The  C/HI)  iniplcineiitation  correctness  theorem  is  a  formula  that  de¬ 
scribes  how  the  f/HU  is  implemented  by  lie'  NS  fill.  \  -sing  SDN’S  Ver¬ 
sion  *».  we  constructed  this  theorem  by  hand,  It*  major  components 
are  as  follows: 

l .  t  In’  behavior  of  l In*  <  ’/HO  in  state  della*  i •  In*  t ratislal ion  «  I  t lie 
ISPS  description  into  slate  deltas) 

■J.  the  Im'Ii.O  iol  of  the  MUM  in  stale  deltas  (the  translation  ol  I  lie 
ISPS  description  into  slate  deltas) 

H.  tin'  ait  ual  m>cinprogiaiu  ill  binary  form 

I.  a  ma ppi nv.  of  the  corresponding  registers  and  oilier  storage 
elejiienis  (tailed  rttrrit  r*  in  IMPS)  of  1  h«*  i'f'M)  description  in 
those  of  the  MUM  desci  iptjilll 

figure  2  ilhist  rales  i  D*  funrt  ioiial  relationships  of  t  lie  dements  of  l  he 
I  hc'orejil. 

Writing  the  theorem  ol  implementation  .md  I  lie  high  level  proof  in 
tie*  inteim  live  mode  required  about  ft  M  IS  months  ol  ellnil.  A  Ii  no  I 
check  on  1  lie  validity  of  the  proof  was  made  by  SDN’S  in  I  lie  batch 
mode.  Tin.,  SDN  S  validation  ol  the*  proof  e.vtuti-d  lm  «ipph»xiui*iic|y 
sfj  hours  on  a  Symbolics  HfiiO  Lisp  Machine,  liven  without  subse¬ 
quent  improvements  t|ml  were  incorporated  into  SDN  S  and  upgrades 
to  the  Symbolics  system,  these  figure's  demonstrate  the  feasibility  ol 
verifying  huge  and  complex  microprograms.  II  this  process  were  to 
he  integrated  into  the  development  cycle  of  micioprogi  a  mined  ma* 
f  hi  lies,  ji  would  greatly  improve  current  debugging/lesting  practice, 
which  often  continues  into  the  applications  phase  of  l lie  product. 


Figure  2:  Microprogram  Verilicaliou  Using  Si) VS,  ( ’imipiitcr  design¬ 
ers  implement  a  computer  instruction  set  by  designing  a  computer  (a 
set  ol  data  paths  and  associated  control  hardware)  together  with  a 
microprogram  that  controls  the  movement  of  data  iviihin  this  com¬ 
puter.  Descriptions  o|  this  instruction  set  and  its  implementation 
are  translated  by  SDVS  into  format  state-delta  semantics.  Tin*  proof 
of  the  implementation  theorem  is  performed  in  the  mathematical 
domain  of  stair  deli  as. 

4  Towards  Implementation  Correctness  at 
Multiple  Levels  of  Design  Detail 

Mem  ii  so  errors  may  be*  introduced  a!  any  level  of  refinement,  a  veri¬ 
fication  system  that  concent  rates  on  a  specific  level  of  design  detail 
is  necessary  but  not  siillieicut  for  the  design  methodology  of  .  rili- 
cal  applications.  During  ttnij  relinement  slep  it  should  he  possible  to 
verify  that  the  new,  lower-level  specificnt  ion  that  has  been  developed 
is  consistent  with  the  higher-level  specification. 

To  dale,  formal  verification  systems  have  focused  on  specific  step*  in 
t In*  relinement  process.  As  we  saw  above.  SDVS  was  developed  to 
verily  tin*  microprogrammed  imr  emeut  a  lion  of  computer  instruct  ion 
sets.  Ollier  formal  verification  .systems  in  use  have  concentrated  on 
verifying  the  refinement,  step  ol  going  from  an  abstract  sperilicaiion 
of  behavior  to  a  system-level  design. 

figure  :J  illustrates  the  process  \ve  envision  of  applying  a  Inn  her 
enhanced  version  ol  SDN’S  to  verifying  implementation  correctness 
throughout  the  design  cycle.  The  light  arrows  in  the  figure  rep. 
resent  steps  in  the  computer-system  implement  a!  ion  (synthesis)  pro 
cess.  Some  ol  these  steps  are  performed  by  means  ol  automated  tools 
(e.g.,  by  l he  roinpihitinii  of  Ada  programs  into  machine  language] 
and  Mime  are  performed  manually  (e.g.,  by  the  imph'iie'iitai imi  of 
microilisl  ructions  by  means  of  data  paths  and  associated  muMol). 
for  every  synthesis  step  there  is  a  corresponding  i i npb*i iu>ii t a i i< >ii - 
vnifn.it ion  step.  'I  he  SDN’S  approach  allows  this  verification  step 
to  be  perloi  uied  using  I  lie  actual  representation  of  1  lie  design  levels 
that  were  used  in  t  lie  synt  liesis  process. 

We  ejiv isjon  the  use  nf  formal  top-level  specifications.  Ada  progi  mis. 
LSI’S  hardware  descriptions,  and  IIDL  circuit  descriptions.  We  suc¬ 
cessfully  tested  l lie  following  assumptions  in  the  C/.’JO  case  study, 
and  expecl  that  they  readily  extend  to  the  multilevel  verilicaliou 
environment: 

•  The  t  l  •auslalioii  of  the  design  represenlal inns  into  state  deltas 
i*  la  it  lifu!. 

•  The  mapping  between  levels  of  design  representation  is  expres¬ 
sive  enough  to  capture  the  correspondence  at  each  level. 

•  I  h  e  correct  ness  theorem  produced  by  the  hupU  nu  nlntwii  com¬ 
mand  represents  the  formal  notion  of  implementation. 
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l  igur«*  .'1:  M uhilcvi‘1  Vcrifi  ration  I'nirm  in  SDVS.  Kadi  stop  in  tin* 
iiuphuiiriitniiou  process  is  unified  I »y  a  process  similar  to  that  in 
I*  i^uro  2.  oxi,«'|>l  liial  I  In*  domains  of  ilu*  descriptions  correspond  to 
I  lie  piirlinilnr  level  of  detail. 


If  wo  apply  our  miiTuprtrgrain  verification  approach  to  developing 
t  In*  implementation- vori  licit  ion  rnvitonmeut  in  othor  domains,  thou 
multilevel  verifies  l  ion  within  l h>-  design  otivironmont  is  feasible. 


5  Conclusions 


Sinn*  its  inception  SDVS  has  focused  on  microprogram  verification 
and  lias  been  viccesshd  in  that  endeavor.  The  tangible  i**s  nits  are  the 
SDVS  tools,  wliuh  have  boon  applied  to  veiil'yiug  tin*  imph'inontation 
of  tin*  C/1M).  Such  a  proof  of  implement  at  ion  correctness  is  important 
in  secure  or  critical  applications  in  which  tin*  discovery  of  errors  as 
late  as  the  operational  stage  is  especially  cost  I  v. 

Ily  its  general  design  SDVS  is  anteiinble  to  implementation  proofs 
at  nntllipit  levels  of  design  detail.  Such  proofs  are  made  feasible  by 
our  efforts  to  expand  llte  set  of  description  languages  processed  by 
SDN’S  [I9|.  Achieving  this  expansion  will  enable  SDVS  to  lake  as  in¬ 
put  the  actual  formal  design  description  used  in  the  CAD  or  (’ASM 
system  for  the  synthesis  of  the  computer.  SDVS  adds  logical  rigor 
to  this  description  by  translating  if  automatically  into  the  underly¬ 
ing  formal  logic  of  SDVS,  and  thus  implementing  a  formal  semantic 
delinilion  of  the  description  language.  The  implementation  theo¬ 
rem  is  also  produced  automatically  by  SDVS  to  reduce  reliance  on 
manual  construction  of  the  correctness  criteria.  Finally,  the  outline 
created  by  tin*  user  to  guide  SDVS  through  the  proof  of  the  imple¬ 
mentation  theorem  can  he  followed  by  a  sophisticated  reader.  These 
h*ati!it‘s  make  SDVS  a  promising  t«»ul  for  increasing  the  confidence 
iti  i  he  correc  tness  of  a  computer  design  and  its  embedded  progjams 
throughout  the  overall  lifecycle. 
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Unlike  many  hard  core  verification  people,  ]  believe  higher 
level  verilicalioii  is  important  in  order  to  derive  l he  relevant 
code  level  specifications  and  relate  them  to  system  proper¬ 
ties.  I  don't  believe  any  existing  system  does  a  good  job 
of  this  at  all.  Without  formal  support  for  such  modeling, 
analyses,  ami  proofs  liovv  does  one  know  what  one  needs  to 
prove  at  lower  levels?  Also,  higher  level  verilicalioii  might 
show  which  program  units  need  to  lie  verified  to  ensure  a 
given  properly.  Why  verily  more  (linn  you  need  to? 

High  level  verifieat ion  is  not  really  distinct  from  code  veri 
lieali  ,11.  In  I >ot 1 1  eases,  there  is  some  mat  hemal  ical  object 
representing  "the  system”,  some  formal  axioms  on  that  ob- 
jeel  representing  what  is  known  or  being  assumed  about  “the 
system",  and  some  formal  statement  of  what  one  wants  to 
prove  about  “the  system".  The  dillerenee  between  what 
I'm  calling  high  level  veriliealioii  ami  code  level  verilicalioii 
is  that  at  the  code  level,  one  has  mole  axioms  about  the 
system  than  one  has  at  the  high  level  (namely,  a  formaliza¬ 
tion  of  the  axiom  "the  system  is  running  the  following  rode 
I  see  verilicalioii  as  a  continuum  from  high  levels 
of  alislraclion  to  low  levels  (where  by  “low  levels”  I  mean 
microcode  and  hardware,  not  just  programming  language 
code).  Hie  problem  with  a  lot  of  "high  level  verifications'" 
in  the  past  is  not  that  they're  too  high  level,  lull  that  the 
axioms  which  Were  assumed  about  the  system  tit  the  high 
level  were  simply  mil  Inti  oflheaciual  system.  (01  course, 
doing  everything  at  a  high  level  does  make  it  harder  to  see 
when  your  axioms  are  false). 

The  danger  with  rode  verification  is  that  it's  hard  to  sec  at. 
the  code  level  whether  the  properties  you're  proving  about 
your  code  are  the  ones  you're  really  interested  in.  With 
high  and  low  level  verilicalioii  in  a  coni iuuinii,  the  prop¬ 
erties  of  the  system  that  the  verilier  really  wants  can  be 
written  down,  and  the  proof  of  this  properly  can  be  reduced 
to  establishing  certain  facts  about  the  code  which,  at  the 
high  level,  are  assumptions.  Code  level  verilicalioii  then 
discharges  these  assumptions  on  the  basis  of  other  assump¬ 
tions  about  compilers,  microcode,  etc.  The  other  benefit  of 
such  a  process  is  that  the  veiilier  might  find  that  lie  can  es¬ 
tablish  the  desired  high  level  property  without  making  any 
assumpl ions  about  certain  parts  of  the  code,  lie  then  knows 
that  lie  need  not  verify  those  parts. 


Is  Code  Verification  Desirable? 

Yes,  as  long  as  we  know  wlial  we're  proving.  Code  verifica¬ 
tion  should  not  be  a  source  of  false  confidence. 


A  number  of  attempts  to  verily  code  (the  CJypsy  KIM,  and 
Message  Flow  Modulator  to  name  two)  and  others  to  verify 
hardware  have  been  successful.  As  lias  been  pointed  out 
before,  the  chief  problem  with  many  of  these  projects  is 
not  that  they  weren't  successful  bill,  that  the  resulting  code 
never  got  used  and  compared  with  unverilied  code  to  do  the 
same  jobs.  I  think  these  projects  demonstrate  tile  leasibilily 
of  code  and  even  lower  level  verilicalioii. 


Wliat  are  Suitable  Applications  lor  Code  Verification? 

1  don't  know  what  applications  ate  most  suitable,  It's  clear 
that  certain  ones  such  as  hard  real  lime  and  iloating  point 
data  types  have  received  only  limited  attention.  In  the  area 
of  verifying  security  properties,  something  smaller  than  a 
full  operating  system,  like  a  network  gateway,  would  be  a 
prime  candidate. 

Other  Questions 

How  close  are  we?  The  key  word  in  your  question  is  useable. 
Useable  bv  who?  Unlike  you,  I  won't  go  on  record  at  Ibis 
point. 

When  could  something  useable  lie  available?  I  think  that 
is  largely  a  question  of  funding  and  the  latter  is  largely  a 
question  of  how  people  perceive  the  benefits. 

There  is  no  doubt  in  my  mind  that  if  HIM  were  to  iliink  ver¬ 
ification  was  important  we  would  have  very  useable  systems 
ill  five  years  and  nene  of  the  people  you  addressed 
your  call  to  would  have  worked  on  them,  it  s  all  a 
question  of  perceiving  the  value.  Perhaps  we  should  add  to 
your  list  the  question: 

Wliat  kind  of  near  term  demonstrations  would  positively 
affect  the  evaluations  of  verification  within? 


My  answers  to  the  specific  questions  proposed  will  locus 
on  those  about  the  value  ol  verification  and  about  the  best 
places  to  put  our  efforts. 
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The  issues  of  integrating  verification  into  software  engineer¬ 
ing  environments  is  important  but  demands  an  hour  itself. 


CODE-LEVEL  VERIFICATION 
(A  Position  Paper) 


Friedrich  W.  von  Henke 
SRI  International 


What  is  “Code  Verification”?  the  computer  hardware. 


Formal  verification  of  programs  started  in  the  1970s  as  verifi¬ 
cation  of  programs  (or  subprograms)  written  in  a  programming 
language  such  as  Pascal  and  augmented  by  specification  con¬ 
structs;  thus,  program  verification  originally  meant  verification 
of  program  code.  Later,  the  main  focus  of  verification  work 
shifted  to  the  specification  and  formal  analysis  of  software  at 
more  abstract  levels,  and  it  became  common  to  make  a  distinc¬ 
tion  between  design  verification  and  code  verification. 

For  the  purpose  of  this  position  paper,  I  want  the  term 
code  verification  to  mean  “formal  consistency  analysis  of  exe¬ 
cutable,  operational  code,  usually  with  the  help  of  mechanized 
tools.”  This  implies  that  code  verification  deals  with  real  pro¬ 
grams  written  in  a  programming  language  in  use  for  production 
software.  The  actual  language  may  be  a  “higher-level”  language 
like  Ada,  or  a  language  closer  to  the  machine,  like  C  or  even  an 
assembly  language. 

In  contrast  to  code  verification,  I  use  code-level  verification 
to  include  formal  analysis  of  programs  in  a  setting  that  is  more 
idealized,  either  by  reducing  the  programming  language  to  an 
impractical  (and  unrealistic)  subset,  or  by  using  a  language  that 
has  been  designed  specifically  for  verification  purposes,  usually 
in  conjunction  with,  or  as  part  of,  a  specification  language.  For 
example,  the  Ehdm  language  [l]  includes  constructs  that  closely 
model  Lhe  main  imperative  features  of  (sequential)  Ada,  such  as 
objects,  assignment,  and  control  flow  constructs. 

Why  Code  Verification? 

Code  (or  code-level)  verification  provides  the  link  between  de¬ 
signs  and  design  specifications  and  what  gets  actually  executed 
on  a  computer.  Thus,  code-level  verification  is  clearly  desirable 
and  needed.  On  the  other  hand,  code-level  verification  by  it¬ 
self  is  not  very  meaningful.  The  specifications  against  which  the 
code  is  to  be  verified  must  have  been  derived  from  the  require¬ 
ments  on  the  system  and  the  system  design.  Indeed,  most  of  the 
modeling  and  analysis  of  system  properties  (such  as  security! 
should  happen  at  higher  (i.e.  design)  levels;  code-level  verifica¬ 
tion  should  be  restricted  to  those  aspects  that  cannot  be  dealt 
with  at  more  abstract  levels,  but  are  sufficient  to  ensure  that 
the  operational  code  indeed  possesses  the  properties  derived  at 
the  higher  levels.  Code-level  verification  also  assumes  that  the 
programming  language  in  which  code  is  written  has  a  formal 
semantics  on  which  the  formal  analysis  can  be  based.  Moreover, 
the  compiler  of  the  language  must  faithfully  implemented  that 
semantics,  so  that  execution  of  the  object  code  reflects  the  se¬ 
mantics  of  the  verified  source.  In  short,  code-level  verification 
is  one  of  several  levels  in  the  specification  and  verification  of  a 
system  that  ideally  extend  from  the  top-level  requirements  to 


Feasibility  of  Code-Level  Verification 

The  basic  technology  for  code-level  verification  has  been  in  ex¬ 
istence  since  the  late  1970s  when  the  first  verification  systems 
became  operational.  (In  my  opinion,  little  progress  has  been 
made  since  then  in  the  verification  of  code.)  Thus,  in  an  elemen¬ 
tary  sense,  code-level  verification  is  “feasible,"  and  has  been  for 
quite  a  while.  On  the  other  hand,  it  would  be  highly  unrealistic 
to  claim  that  the  present  state-of-the-art  allows  us  to  take  an 
arbitrary  program  written,  say,  >n  Ad:t  and  “verify”  it.  There 
arc  quite  a  number  of  aruas  that  still  require  extensive  research 
and  development  efforts;  for  example: 

•  Likely  application  aieas  for  code-level  verification,  such 
as  real-time  behavior  and  distributed  systems,  are  lacking 
the  mathematical  foundations  for  formal  specification  and 
reasoning  and/or  the  mechanical  support  for  substantial 
verification  efforts.  For  concurrent  and  distributed  sys¬ 
tems,  a  substantial  body  of  theoretical  results  exists,  but 
none  of  the  existing  verification  systems  that  ]  am  aware 
of  adequately  supports  reasoning  about  such  iystems. 

•  Code-level  verification  must  support  more  realistic  subsetii 
of  the  actual  programming  language. 

•  Tools  and  techniques  need  to  be  refined,  based  on  extensive 
experience,  to  make  them  really  practical. 

In  short,  substantial  research  and  development  efforts  are  still 
required  for  realistic  code  verification, 

In  addition,  alternatives  to  code  verification  need  to  be  ex- 
pior  d  further.  For  example,  the  approach  taken  in  the  Ehdm 
system  [l)  is  to  avoid  formal  reasoning  about  actual  program 
text  completely.  Instead,  the  specification  language  itself  in¬ 
cludes  constructs  sufficient  to  specify  concrete  algorithms  at  the 
same  level  of  detail  (and,  if  desired,  in  the  same  imperative  style) 
as  actual  code,  and  all  formal  analysis  is  carried  out  within  the 
same  formal  system  as  the  design  verification.  Once  such  a  code- 
level  specification  or  “abstract  program”  has  been  demonstrated 
to  be  consistent  wit’  higher-level  specifications,  it  can  be  con¬ 
verted  into  Ada  tex.  oy  a  translator  provided  in  the  Ehdm  en¬ 
vironment. 

Such  an  approach  appears  more  in  line  with  a  systematic 
development  process  that  involves  design  specifications  and  ver¬ 
ifications;  the  programming  language  code  is  regarded  as  the 
target  of  a  systematic  development,  in  contrast  to  the  tradi¬ 
tional  view  that  takes  it  as  the  starting  point  of  the  verification 
effort.  However,  this  approach  does  not  eliminate  the  Inher¬ 
ent  complexity  of  code-level  verification;  what  can  be  avoided  is 
163 


having  to  deal  with  some  of  the  idiosyncrasies  of  programming 
languages  designed  for  efficiency  (of  compilation  or  execution) 
rather  than  logical  clarity.  (The  current  ElIDM-to- Ada  trans¬ 
lator  is  an  experimental  tool  and  far  from  being  practical,  in 
particular  since  the  Ada  subset  that  can  be  modeled  in  EHDM 
is  still  unrealistically  small.) 

Like  all  formal  verification,  code-level  verification  is  very  ex¬ 
pensive.  I  doubt  that  this  will  change  in  the  near  term,  even  with 
substantial  efforts  to  develop  better  tools  and  techniques.  Ver¬ 
ification  deals  with  semantic  issues,  which  are  inherently  com¬ 
plex  (and  often  intractable,  i.c.  unsolvable,  in  full  generality). 
Thus,  fully  automated  tools  that  can  be  used  as  easily  as  a  com¬ 
piler  will  be  developed  only  for  small,  well-understood  -  and 
well-formalized  -  areas,  and  formal  verification  will  remain  an 
interactive,  labor-intensive  activity. 

This  inherent  cost  obviously  reduces  the  usability  of  formal 
code-level  verification.  If  much  of  the  formal  analysis  lias  been 
carried  out  at  higher  (i.e,  design)  levels,  the  additional  expected 
benefit  derivable  from  formally  verifying  the  code  may  not  be 
large  enough  to  justify  the  cost,  except  for  small,  crucial  code 
segment.  Tor  example,  correct  behavior  of  the  separation  kernel 
in  a  secure  system  is  critical  and  should  be  subject  to  formal  ver¬ 
ification.  This  example  indicates  that  it  may  he  more  important 
to  focus  code-level  verification  efforts  on  low-level  programming 
languages,  which  are  more  likely  to  be  used  for  critical  code 
segments  than  higher-level  languages  such  as  Ada. 

For  general  applications,  a  more  cost-efficient  alternative 
may  bo  to  use  less  formal,  but  nevertheless  rigorous,  methods 
such  is  IllM’t)  Clean  Room  methodology  or  VUM.  Experience 
with  these  methods  demonstrates  the  importance  of  educating 
the  potential  users  for  the  usefulness  and  acceptance  of  formal 
methods. 

Code-Level  Verification  and  Software  Develop¬ 
ment 

ft  is  obvious  that  the  real  benefit  is  derived  from  formal  specifi¬ 
cation  and  verification  when  it  is  part  of  the  general  system  de¬ 
velopment  process  and  when  the  verification  tools  are  integrated 
with  the  software  environment.  As  a  last  step  in  a  development 
based  on  formal  specifications,  the  specifications  derived  at  the 
lowest  design  level  can  be  used  to  guide  the  production  of  the  ac¬ 
tual  code;  consistency  between  the  code  and  the  specifications 
can  then  be  checked  by  code-level  (or  code)  verification.  I’d 
hope,  however,  that  future  development  of  formal  methods  and 
associated  support  tools  will  shift  the  perspective  from  analytic 
to  synthetic  approaches,  so  that  code  will  he  constructed  from 
low-level  specifications  and  code  verification  in  the  tradili  ual 
sense  will  become  obsolete. 
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The  following  are  my  responses  to  the  questions 
that  were  posed  to  the  panel. 

Is  code  level  verification  feasible?  Desirable? 

There  is  no  doubt  that  code  level  formal 
verification  is  feasible.  Unfortunately,  the  conclusion 
that  1  made  after  working  on  the  formal  verification  of 
the  UCLA  Data  Secure  Unix  project  in  1978  still  holds. 
That  is,  the  techniques  necessary  for  formal 
verification  (both  design  level  and  code  level)  are 
available;  what  is  needed  is  engineering  to  produce 
production  quality  formal  verification  systems.  What  1 
realize  now  is  that  to  achieve  a  production  quality 
product  will  require  a  profit  oriented  company  to 
decide  that  they  are  interested  in  formal  verification. 

The  answer  to  the  desirability  question  is  an  obvi¬ 
ous  yes.  Of  course  it  Is  desirable  to  increase  one's 
assurance  that  a  piece  of  code  will  perform  as 
expected. 

What  applications  are  most  suitable  for  code 
level  verification? 

Formal  specification  and  verification  should  be 
used  in  all  software  development  projects.  This  does 
not  mean  that  it  is  necessary  to  use  a  formal 
verification  system,  but  that  one  should  reason  about 
their  programs  and  use  formal  notation  as  their  design 
documentation.  Many  of  the  problems  that  occur  in 
software  development  projects  are  the  result  of  pro¬ 
grammers  rushing  off  and  generating  code  without 
thinking  about  the  design.  By  using  formal  notation 
for  the  design  documents  one  can  reason  rigorously 
about  the  design  (again  not  necessarily  with  the  aid  of 
a  verification  system)  before  writing  any  code.  When 
the  code  is  finally  produced,  they  can  then  formally 
verify  that  the  code  is  consistent  with  its 
specifications. 

How  close  are  we  to  having  usable  verification 
systems  for  code  level  verification? 

As  was  mentioned  in  the  response  to  the  first 
question,  the  necessary  techniques  have  been  available 
for  more  than  a  decade.  However,  what  is  needed  is 
an  interested  party,  that  Is  willing  to  take  the  research 
tools  and  turn  them  into  a  product.  None  of  the  exist¬ 
ing  formal  verification  tools  can  be  considered  to  be  a 
product  (whether  they  can  accommodate  code  level 
verification  or  not), 


I  am  not  necessarily  suggesting  that  one  of  the 
existing  tools  be  used  as  a  base,  but  rather  that  the 
experience  gained  from  using  these  tools  be  applied 
to  a  new  product.  I  also  feel  that  this  will  be  carried 
out  by  a  profit  oriented  corporation  and  not  by  one  of 
the  research  groups  that  are  responsible  for  the  exist¬ 
ing  tools.  The  stress  here  is  on  "development".  The 
know-how  already  exists,  what  is  needed  Is  the 
development  of  a  friendly  human  interface,  good 
documentation,  production  quality  packaging,  market¬ 
ing,  etc. 

Regarding  the  time,  three  to  five  years  is  needed 
to  produce  a  product.  However,  what  is  needed  first  is 
the  desire  to  have  a  product  or  the  vision  to  sec  its 
marketability. 

How  will  code  level  verification  fit  into  the 
software  development  process? 

As  was  mentioned  in  the  response  to  the  first 
question,  the  only  way  to  develop  systems  is  to  use 
formal  specifications  us  the  design  notation.  This  can 
be  in  the  form  of  a  rigorously  defined  language  whose 
specifications  arc  machine  checkable  or  in  more  gen¬ 
eral  notation,  such  as  the  set  notation  of  Z,  which  is 
not  currently  machine  checkable.  These  formal 
specifications  allow  the  designers  to  rigorously  answer 
questions  about  their  designs.  The  higher  level  design 
specifications  should  be  refined  as  the  design 
progresses.  Finally,  the  lowest  level  design  should  be 
used  to  generate  the  necessary  entry  and  exit  asser¬ 
tions  for  the  code.  This  would  be  similar  to  the 
approach  I  used  for  the  secure  terminal  with  Ina  Jo 
(See  the  Verification  Assessment  Report  Volume  IV.). 

How  expensive  will  it  be  in  people  time,  machine 
time  and  money? 

1  believe  that  one  of  the  biggest  expenses  will  be 
in  training  software  developers  to  use  formal  tech¬ 
niques.  However,  once  they  are  trained  the  increased 
reliability  of  the  software  will  counter  any  added 
development  cost.  In  addition,  when  the  system  is  in 
the  maintenance,  phase  the  cost  of  maintenance  should 
be  reduced  due  to  the  availability  of  the  unambiguous 
formal  documentation.  Therefore,  the  cost  over  the 
lifetime  of  the  system  should  not  increase 
significantly,  if  at  all. 
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Afterthought 

I  believe  it  is  worth  mentioning  that  one  can  not 
expect  to  take  an  already  existing  piece  of  code  and 
formally  verify  that  it  does  what  It  is  supposed  to.  If  a 
system  is  to  be  formally  verified  it  is  necessary  to  plan 
for  the  forma!  verification  from  the  start  of  the  pro¬ 
ject.  Before  any  code  is  written  it  is  necessary  to  sit 
down  with  the  developers  and  discuss  the  coding 
practices  that  should  be  adhered  to  to  simplify  the 
formal  verification  process.  For  instance,  if  the 
developers  are  planning  to  use  pointers  in  their  Imple¬ 
mentation  the  cost  of  formally  verifying  the  code  is 
going  to  increase,  and  if  they  plan  to  use  pointer  arith¬ 
metic  the  task  may  be  infeasible.  In  like  manner,  using 
a  language  feature  like  the  Pascal  variant  record  will 
increase  the  cost  of  the  formal  verification  process. 
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How  Soon  for  Code  Level  Verification? 
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Twenty  years  have  passed 

This  panel  was  bom  out  of  sense  of  frustration  and  wonder.  It’s 
been  two  decades  since  Floyd  published  his  landmark  paper  on 
program  verification.  [Floyd  67 )  Shortly  thereafter.  King 
completed  the  first  working  program  verification  system  [King  69], 
and  the  field  was  in  full  bloom.  Further  landmark  work  followed 
from  lloare,  e.g.  IHoare  691  and  a  number  of  verification  systems 
were  built.  With  that  start,  we  might  expect  that  twenty  years  later 
program  verification  would  be  an  established  technology.  However, 
in  my  knowledge,  not  a  single  program  operating  in  the  field  has 
been  verified  at  the  code  level! 

To  be  fair,  there  lias  been  considerable  progress  in  verification  over 
tlie  past  twenty  years.  A  very'  substantial  fraction  of  the  financial 
and  intellectual  resources  of  the  field  have  been  focused  on  two 
particular  aspects  of  verification,  design  verification  and 
programming  language  semantics. 

"Design  verification",  as  most  of  this  audience  knows,  is  verification 
of  die  consistency  between  an  abstract  design  of  a  system  and  a 
formal  statement  of  the  security  policy  the  system  must  adhere  to. 
Code  level  verification  can  only  prove  the  consistency  between  the 
code  and  a  specification.  If  die  specification  is  incorrect,  the  code 
level  proof  will  not  be  of  much  use  in  establishing  the 
trustworthiness  of  the  code. 

One  community  that  recognized  the  importance  of  verification  was 
die  security  community.  The  key  concern  within  the  security 
community  is  that  systems  protect  information  that  is  entrusted  to 
them.  Hence,  no  matter  what  else  the  system  is  supposed  to  do,  it  is 
obligated  to  protect  the  information  in  it..  It  is  no  surprise,  then,  that 
considerable  attention  was  given  to  die  assuring  that  the  overall 
design  of  a  system  adhered  to  the  security  requirements  in  particular. 

This  attention  to  design  level  verification  has  been  so  substantial  that 
it  completely  overshadowed  the  original  focus  on  code  level 
verification.  When  the  Trusted  Computer  System  Evaluation 
Criteria  [TCSlil’l  was  drafted,  the  technology  to  support  design 
level  verification  appeared  mature  enough  tu  include  in  the  criteria, 
but  code  level  verification  technology  was  not.  The  Criteria 


contains  a  place  holder  called  "Classes  Beyond  Al."  Hie  criteria 
applicable  to  these  classes  have  not  been  determined  fully,  but 
verification  down  to  the  code  level  is  clearly  expected:  "Ihe  ’1CB 
must  be  verified  down  to  the  source  code..."  [TCSEC,  page  53) 

Tlie  verification  community  also  turned  its  attention  to  die  semantics 
of  programming  languages.  Fortran,  Cobol  and  PL/1  dominated  tlie 
set  of  programming  languages  in  common  use  in  the  late  1960s  and 
early  1970s.  Different  branches  of  DoD  were  using  languages  of 
their  own  invention  --  JOVIAL,  CMS-2,  CS-4,  TACPOL,  etc.  In  all 
cases,  the  semantics  of  the  languages  were  difficult  to  formalize, 
The  only  definitive  authority  for  the  meaning  of  a  particular 
program  was  how  it  executed  when  compiled  by  a  particular 
compiler  and  executed  on  a  particular  computer.  A  traction  of  the 
verification  community  focused  on  how  to  formalize  die  definition 
of  programming  languages  and  how  to  design  programming 
languages  with  precise  semantics.  It  is  perhaps  instructive  to  note 
that  while  these  efforts  have  yielded  major  new  insights  into  the 
mathematical  foundations  of  programming  languages,  the  two  most 
widely  used  new  languages  tire  Ada  and  C,  neither  of  which  is 
widely  regarded  as  having  a  significantly  better  defined  semantics 
than  older  programming  languages. 

Meanwhile,  experience  has  been  gained  with  using  design 
verification  to  provide  assurance  that  a  computer  system  w'ill  protect 
information  entrusted  to  it.  The  experience  is  mixed,  and  some 
question  whether  the  process  adds  much  assurance  at  all.  Sec,  lor 
example,  (Schaefer  XX [  for  a  discussion  of  this  point.  But 
disregarding  the  question  of  whether  it’s  beneficial,  tlie  process  is 
undeniably  expensive  and  error-prone.  Design  verification  is 
necessarily  disconnected  from  the  code.  This  means  that  elloits  to 
maintain  correspondence  depend  on  a  great  deal  of  labor  and  a  great 
deal  of  discipline.  And,  of  course,  even  with  full  attention  and 
discipline,  the  formal  basis  for  the  design  and  the  code  semantics 
may  be  incompatible  in  some  respects,  That  is,  die  assumptions  in 
the  formal  design  may  not  match  the  facilities  provided  by  the 
hardware  and/or  compiler. 

Focus  of  this  panel 

With  this  background,  it  is  perhaps  tittle  to  re-examine  the  otiginal 
vision  of  code  level  verification.  To  stimulate  discussion  on  this 
point,  1  proposed  this  panel  and  invited  a  number  ot  leading 
verification  researchers  to  participate.  Tlie  invitation  included  tlie 
following: 
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How  Soon  for  Code  Level  Verification? 

The  exciting  payoff  for  verification  will  be  its 
application  to  code  level  proofs  where  it  will  provide 
strong  correspondence  between  operational  code  and 
top  level  specifications.  The  purpose  of  this  panel  is 
to  bring  together  practitioners  of  the  art  -  particularly 
verification  system  developers  —  and  to  describe  the 
steps  toward  achieving  wide-spread,  efficient  code 
level  verification.  Contrary  views,  e.g.  code  level 
proofs  are  impossible,  code  level  proofs  are 
undesirable,  code  level  proofs  will  always  be  loo 
expensive,  will  also  be  explored.  To  provide  a 
coherent  basis  discussion,  each  panel  member  will 
address  the  same  set  of  questions.  The  floor  will  then 
be  open  for  the  panel  members  to  debate  with  each 
other  and  to  respond  to  questions  from  the  floor.  The 
common  questions  include: 

o  Is  code  level  verification  feasible? 

Desirable? 

o  What  applications  arc  most  suitable 
for  code  level  verification? 

o  tlow  close  arc  we  to  having  usable 

verification  systems  for  code  level 
verification? 

o  How  will  code  level  verification  fit 

into  the  software  development 
process? 

o  How  expensive  will  it  he  in  people 

time,  machine  lime  and  money? 

I  asked  further  that  prospective  panelists  agree  to  prepare  short 
position  papers,  and  that  some  discussion  and  debate  take  place  prior 
to  the  conference  so  that  we  would  present  related  and  comparable 
views,  although  hopefully  not  blandly  identical  views. 

Each  of  the  panelists  lias  played  a  major  role  in  the  development, 
assessment  and/or  use  of  verification  systems  in  recent  years. 
Specifically: 

Dan  Craigcn  has  been  leading  the  development  of  the 
m-EVES  program  development  system  and 
previously  participated  in  the  development  of  Euclid. 

Dick  Kcmmerer  worked  on  a  major  effort  to  verify  a 
version  of  Unix,  has  contributed  various  techniques 
for  analysis  of  information  flow  properties  and 
analysis  of  Ada  programs,  and  led  an  extensive  effort 
to  assess  the  current  technology  in  verification, 
resulting  in  a  five  volume  report  |  Kcmmerer  8b|. 

Richard  Platek  is  the  founder  and  president  of 
Odyssey  Research  Associates  (ORA).  Under  his 
direction,  ORA  has  become  a  major  builder  of 
verification  systems. 


Friedrich  von  Henke  is  the  prime  architect  of  the 
Enhanced  HDM  (EHDM)  at  SRI  International,  and 
has  been  a  leading  contributor  to  the  theory  and 
development  of  verification  systems  for  several  years. 

The  views  of  these  people  arc  sketched  in  their  position  papers  in 
these  proceedings.  Many  other  researchers  have  strong  and  relevant 
views,  but  the  limitations  of  space  and  time  restricted  us  to  this 
panel.  If  tire  issues  discussed  by  these  panel  members  are  deemed 
appropriate  for  further  discussion,  perhaps  the  debate  will  continue 
in  another  forum. 

My  own  view 

it  should  come  as  no  surprise  that  1  am  optimistic  about  the 
prospects  for  code  level  verification. 

Is  code  level  verification  feasible?  Desirable? 

The  "desirable"  part  is  easy,  and  answered  in  part  in  the  description 
of  design  verification.  A  very  large  class  of  bugs  will  cease  to  exist 
when  code  is  verified  before  it  is  fielded,  and  the  resulting  increase 
in  reliability  will  be  extremely  valuable. 

How  feasible  is  code  level  verification?  I  take  the  somewhat  radical 
view  that  programmers,  on  tire  average,  know  wiry  they  write  the 
code  they  do,  and  that  tlicii  knowledge,  although  informal  and  often 
unexpressed,  constitutes  the  elements  of  a  proof.  Therefore,  only  the 
"trivial"  task  remains  to  provide  tools  to  tltese  programmers  to 
express  their  knowledge  in  a  formally  acceptable  way. 

This  view  lias  a  number  of  ramifications.  First,  it  implies  that  the 
vast  set  of  existing  programs  are  fair  game  to  specify  and  verify. 
The  argument  often  heard  that  only  programs  written  in  new 
languages  and  following  new  paradigms  are  verifiable  is 
misdirected.  The  fundamental  reasoning  processes  for 
understanding  programs  already  exist  within  the  minds  of 
work-a-day  programmers.  New  languages  and  new  paradigms  may 
provide  modest  help,  but  the  more  useful  challenge  is  to  find  ways  to 
express  what  programmers  already  know, 

Another  ramification  is  that  it  is  botli  possible  and  necessary  for 
program  verification  systems  to  work  with  the  same  languages  that 
programmers  use  to  build  real  systems.  If  the  verification 
community  insists  that  new  languages  arc  needed,  it  has  taken  on  the 
extremely  hard  problem  of  convincing  the  entire  programming 
community  to  use  those  languages.  Generally  -  Ada  excepted  — 
programming  languages  have  been  wideiy  adopted  only  when  they 
have  provided  a  new  level  of  expressive  power  and  have  had 
efficient  translators. 

Third,  it  seems  entirely  possible  thut  "ordinary"  programmers  will 
use  verification  systems.  Verification  specialists  -  at  least  in  the 
sense  of  people  who  prepare  specifications  and  proofs  for 
verification  systems  -  may  not  be  necessary  in  the  future. 
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What  applications  are  most  suitable  for  code  level  verification? 

Given  that  the  central  issue  in  verification  is  explicating  and 
formulating  the  knowledge  programmers  bring  to  bear  in  the  design 
of  their  programs,  it  makes  sense  to  start  with  the  domain  of 
programs  that  embody  the  least  knowledge:  systems  programs.  All 
programs  embody  considerable  knowledge  of  computers  and 
computing.  Applications  such  as  weather  prediction,  inventory 
control,  stock  market  analysis,  etc.  also  embody  considerable 
knowledge  about  domains  well  outside  of  computer  science.  System 
programs,  on  the  other  hand,  have  far  less  connection  with  the  real 
world  and  are  much  more  easily  formalized. 

Ilow  close  arc  we  to  having  usable  verification  systems  for  code 
level  verification? 

First,  it  is  important  to  understand  wluu's  meant  by  "usable."  I  have 
in  mind  criteria  similar  to  the  use  of  a  compiler  01  other  tool.  A 
verification  system  is  usable  only  if... 

...It  can  verify  programs  written  in  widely  used  programming 
languages,  with  essentially  no  restriction  on  the  use  of  the  language, 
i.o.  without  restricting  the  programming  language  to  a  weak  subset. 

...It  comes  with  a  specification  language  that  permits  pleasing  und 
concise  expression  of  the  important  behavioral  and  performance 
properties  of  programs. 

„,lt  comes  with  tin  algorithmic,  i.e.  predictable,  proof  system  of 
sufficient  power  to  keep  the  proofs  short. 

Interactive  theorem  provers  may  be  helpful  for  the  same 
reason  that  interactive  program  development  systems  are,  but 
a  programmer  should  never  be  in  doubt  as  to  whether  the 
proof  system  is  smart  enough  to  sec  the  trust  of  a  particular 
assertion  in  a  given  context.  At  the  same  time,  it  is  not 
acceptable  to  achieve  predictability  and  lose  conciseness.  A 
proof  system  that  requires  the  user  to  supply  every  modus 
[wnais  and  every  instantiation  is  not  usable. 

...It  is  fast  enough  to  be  used  unhesitatingly,  i.e.  as  often  as  the  user 
would  ordinarily  use  the  compiler. 

In  specific  terms,  this  means  a  modern  day  verification 
system  needs  accept  a  combination  of  specification,  code  and 
proof  and  check  the  proof  within  a  factor  of  3  or  so  us  fast  as 
the  compiler  would  compile  that  program.  I  haven’t  check 
the  speed  of  modern  day  compilers,  but  l  believe  they 
compile  tens  to  hundreds  of  lines  per  minute.  The  factor  of 
three  is  my  rough  guess  as  to  wha!  the  user  will  perceive  as 
comparable  to  the  speed  of  compilation.  Perhaps  the  factor 
should  be  icss  than  2  or  as  much  as  10.  in  any  case,  a 
verification  system  is  not  usable  if  it  takes  hours  to  verify  a 
program  that  compiles  in  minutes  or  seconds. 

With  all  of  these  provisos,  1  believe  it  is  possible  to  build  usable 
verification  systems  in  three  to  five  years.  To  do  so,  it  is  important 
to  limit  the  attention  to  existing  programming  languages  and  not 
design  a  new  language  in  tandem  with  designing  the  verification 
system.  It  is  equally  important  to  set  as  a  ground  rule  that  the 
verification  system  will  be  predictable.  Many  important  algorithms 
are  known  for  implementing  decision  proceduies.  and  many  more 
are  yet  to  be  discovered,  but  these  are,  I  believe,  less  important  than 
providing  an  understandable  interface  for  the  programmer. 


The  last  two  questions,  how  will  code  level  verification  fit  into  the 
software  development  process  and  how  expensive  will  it  be  to  use 
such  systems,  have  been  answered  at  least  partly.  Well  constructed 
verification  systems  will  fit  into  the  software  development  cycle  at 
the  same  place  and  in  the  same  manner  as  compilers.  Code  will  Ire 
verified  as  it  is  written  or  changed,  and  if  desired,  reverified  as  part 
of  acceptance  procedures.  More  people  and  money  may  be  needed 
to  formalize  what  programs  are  supposed  to  do,  but  NO  additional 
time  or  money  should  be  needed  to  verify  programs  as  they  are 
being  written.  And,  of  course,  the  increase  in  quality  of  programs 
will  lead  to  a  substantial  decrease  in  the  cost  of  maintenance  of 
programs. 
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The  first  point  that  struck  me  about  the  description  of  the 
problem  to  lie  discussed  is  I  lie  apparent  merger  of  two  orthogonal 
concerns:  the  nst*  of  formal  methods  during  the  programming 
development  process,  on  the  one  hand,  and  the  application  of 
systems,  which  support  the  application  of  formal  methods,  on 
t  he  ot  her. 

it  is  my  belief  that  any  sell-respecting  computing  scientist 
should  he  aide  to  informally  (hut  rigorously)  justify  that  their 
program  satisfies  the  specification  describing  their  task.  Tech- 
nitpies  have  been  available  for  well  over  a  decade  and  new  ways 
ol  reasoning  about  programs  are  continually  being,  developed. 

IT0111  this  first  perspective  I  would  answer  the  four  relevant 
ipiesl  ions  I  hwsly: 

•  Is  code  level  verification  feasible?  Desirable?  Yes  and 
Yes. 

•  What  applications  are  most  suitable  for  code  level 
verification?  Most  work  to  date  has  been  based  on  vari¬ 
ants  of  the  pre-post  form  of  verification.  Other  techniques 
such  .is  CSR.  CVS  and  ('oust rut-live  Type  Theory,  are  ex¬ 
tending  otn  manipulative  capabilities.  More  work  needs  to 
he  performed! 

•  How  will  code  level  verification  fit  into  the  software 
development  process?  There  is  nothing  antithetical  to 
good  software  development  ptocesses  in  the  application  of 
formal  methods.  One  expects  a  ptnvei  fill  svnergism. 

•  How  expensive  will  it  be  in  people  time,  machine 
time  and  money?  1  would  expert  ilia l  disciplined  and 
rigorous  development  ot  systems  would  be  more  cost  ellec 
live.  However,  I  do  not  know  of  any  studies  which  have 
investigated  this  contention. 

On  wild  111 -I  We  should  lie  applying  verilical  ion  systems  to  t  isle 
level  plouls.  I  li is  is  a  more  contentious  issue  and  generalizes  In 
whether  current  verilical  imi  systems  should  lie  used  at  all.  In 
"thei  pa  pels  [|]  it  has  been  argued  llial  t  he  appln  at  Ion  of  vei  >li 
■  nl iiui  sysl fins  have  three  (putative)  benefits:  soundness,  nuigiii 
fi*  at  ion  and  I  racking.  I  licse  propel  I ies  are  not  as  lunda menial  as 
I  lie  hi  I  v.i  ul  ages  I  hat  should  a.  .rue  Iroui  disciplined  thought  but 
■ire.  neverl  lieless,  important . 

So.  reluming  to  the  listed  questions: 

•  Is  code  level  verification  feasible?  Desirable?  With 
i  in gently  endorsed  tools,  fiol fi  tfie  feasibility  and  dcsiruhjlii  v 
is  questionable.  Desirability  is  for  (lie  rust omcr  to  make  an 
inlorineil  decision  based  upon  their  organization's  mission. 
Il  is  obi  mils  that  ninri  powerful  looks  are  necessary;  espe¬ 
cially  m  terms  of  specification  and  programming  languages, 
m.iiliemalical  logics,  and  supporting  media nized  proving 

systems. 


•  What  applications  are  most  suitable  for  code  level 
verification?  Most  work  to  dale  has  been  bused  on  vari¬ 
ants  ol  (lie  pie- post  form  of  verilical  ion.  Ollier  techniques 
such  as  CSP,  (VS  and  Const  ru<  live  Type  Theory  are  ex¬ 
tending  our  manipulative  capabilities.  More  work  needs  to 
be  performed! 

•  IIow  close  are  we  to  having  usable  verification  sys¬ 
tems  for  code  level  verification?  Obviously.  I  have  my 
own  axe  to  grind  here  ( 1  ] .  It  is  my  contention  I  lint  some 
current  developments  are  moving  towards  systems  which  are 
based  on  sound  mat  lieu  in  I  ics  and  apply  state  of  t  lie  art  tech¬ 
niques  in  theorem  proving  and  language  design.  Uinloiilil- 
edly.  since  fixed  formalisms  and  languages  are  chosen  there 

will  be  problems  which  either  cannot  he  addressed  or  will 
be  handled  in  an  linwieldly  manner. 

•  How  will  code  level  verification  fit  into  the  software 
development,  process?  Verification  systems  must  lie  inte¬ 
grated  with  general  software  development  tools. 

«  How  expensive  will  it  be  in  people  time,  machine 
time  and  money?  I  do  not  know  of  any  . studies  t  fiat  hate 
investigated  this  issue. 

finally,  while  I  have  responded  in  terms  of  l  he  panel,  I  should 
note  that  il  is  clear  that  there  is  mole  to  loniial  methods  I  linn 
specilical  ion  and  code  proofs.  Kirilial  Methods  can  be  viewed  as 
the  application  of  mat lieniat ieal  discipline  to  (lie  entile  system 
development  process.  One  of  the  more  interesting  projivls  taking 
this  view  is  I  lie  Trusted  Systems  work  at  Computational  Logic. 
Inc.,  with  their  work  on  micro  ( .‘vpsy,  I’ilon  and  the  h'Mx.'iOI. 
Others  are  better  qualified  to  report  on  dial  work. 
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Abstract 


This  paper  describes  a  demonstration, 
implemented  as  application  code  executed  by 
entrusted  subjects  in  the  environment 
provided  by  a  high-assurance  security 
Kernel  (GEMSOS)  that  provides  multi-level 
database  management  services  using  a 
significant  subset  of  the  entity- 
relationship  data  model.  The  demonstration 
inr'-'ides  the  essential  data  management 
so’  ' one  i  aid  expect  to  find  in  the 
i.i.1. i  ■  -anw  nucleus  of  a  DBMS,  supporting  the 
concept  of  entities,  relationships  between 
entities,  and  the  abJlity  to  merge  data  (u- 
viewed  by  the  user)  from  all  visible 
sensitivity  partitions.  The  merged  data  is 
logically  integrated  into  a  single  data 
model  for  query  and  manipulation 
( ■.  ..insistent  w:'h  the  security  policy)  by 
i'.-.a  user.  The  significance  of  the 
demonstration  is  that  this  is  one  of  the 
e,-.  Host  demonstrations  proving  that, 
significant  programs  managing  complex  data 
structured  contai  Hug  d ita  of  differing 
.sensi  i.-'i  v..'  ties  can  be  efficiently 
implem,--:!  ted  as  an  opi ication  executed  by 
an  uni  rusted  subject,  e '-in strained  by  a 
genu-  a  high- asxui  ar.fc  security  kernel. 

1 .  .ntro.'uc  Cion 

The  Multilevel  Secure  Entity- Relationship 
DBMS  Demons tr  7 1 ion  (  ER/DBMS  )  is,  a 
demonstration  of  certain  of  the  technical 
concepts  neve  1  j,.  .  1  .tor  the  Secure  Entity- 
Relations'  .  -abate  Management  System 
design  produced  by  AOG  Systems,  Inc.  and 
Gemini  Computers,  Inc.  under  contract  to 
the  Rome  Air  Do-,  e  1  fusmon  t  Center,  (  RADC ) , 
United  States  Air  rorce  ( Contract  F30G03- 
86-C-0117 ) .  -fie  technical  goa  s  cf  the 
domenu  Ci ion  were  as  follows: 

*>  Ic  demonstrate  that  untreated 

applications  can  share  and  men '.pul ate 
data  in  the  form  of  complex, 
multilevel,  dynamic  data  structures 
wife  a  high  apparent  granularity  of 
classification. 

•  More  specifically,  to  impl  ment  the 
critical  components  of  the  multilevel 
GTERM  data  model  [1],  including  a 
demonstration  of  entities  with 
attributes  of  diff.  ring  sens' tivity, 
relationships  between  entities  of 
differing  sensitivities,  maintenance 
of  an  index  structure  for  types  of 
entities  (namespaces),  and  the 
polyinstentiaf .'  on  of  attributes  ( that 
is,  support  for  multiple  versions  of 
the  same  attri*-.  te,  visible  to 
appr  •  ri .  . ely  clf-red  users  only). 


•  To  demonstrate  the  transitions  between 
a  user's  interaction  with  a  Trusted 
Computer  Base  ( TCB ) ,  untrusted 
applications,  and  trusted 
applications,  including  use  of  a 
trusted  path,  secure  login  and  logout 
procedures,  and  changes  in  session 
level . 

•  To  gain  experience  in  the  design  of 
screen-oriented  human  interfaces 
implemented  as  an  untrusted 
application  presenting,  to  the  user, 
data  copied  from  repositories  of 
various  sensitivities. 

As  important  to  the  design  of  the 
demonstration  as  its  objectives  are  those 
capabilities  chosen  not  to  be  demonstrated. 
The  design  simplifications  chosen  included 
the  following: 

•  The  database  uses  a  fixed  schema  of 
three  entity  types  and  two 
relationship  types  representing  a 

t  -leal  application;  there  is  no 
Cbi cOility  to  modify  the  schema, 

•  Only  a  single  user  is  supported,  so 
that  concurrent  manipulations  of  the 
database  are  not  encountered. 

•  The  database  is  low-volume  (a  maximum 
of  100  items  of  each  type  is 
supported)  so  that  storage  management 
Is  very  simple. 

•  The  only  concern  with  algorithm 
selection  and  data  structure  design 
for  processing  efficiency  was  to  avoid 
a  demonstration  that  appeared  slow. 

•  No  support  for  multiple,  concurrent 
transactions  is  provided: 
essentially,  each  logical  query, 
update,  or  addition  is  treated  as  an 
atomic,  sequentially-executed 
transaction. 

•  No  support  for  the  deletion  of  data  is 
provided. 

•  Only  two  levels  of  data  sensitivity 
(SECRET  and  TOP  SECRET)  are  supported. 
The  -  issues  related  to  the  potential 
ex  •  i  ;e  of  very  large  numbers  of 

acx  jlasses  are  avoided. 

«  No  discretionary  access  control  policy 
in  supported. 

Although  many  of  the  design  simplifications 
chosen  al lowed  issues  to  be  avoided  that 
are  clearly  of  concern  for  the  design  of  a 
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commercial  quality  multilevel  DBMS, 

(notably,  the  need  for  concurrency  and 
transaction  support)  the  selection  of  those 
capabili cies  to  be  demonstrated,  and  those 
not,  was  deliberately  made  to  support  the 
primary  goal  of  the  demonstration  --  to 
explore  data  structure  solutions  allowing 
data  of  multiple  sensitivities  to  be  re¬ 
assembled  into  an  integrated  view  for  an 
appropriately  cleared  user,  and  to  allow 
the  data  structure  to  be  consistently 
updated  without  violating  the  security 
constraints  by  an  untrusted  subject. 

Some  of  the  design  simplifications  (such  as 
those  avoiding  concurrency  controls)  were 
made  because  we  felt  that  adequate 
solutions  are  already  known  --  e.g., 
controls  based  on  the  use  of  eventcounts 
and  sequencers  or  their  equivalents  ([2], 
[3],  and  [4]). 

Other  problems  not  examined  (e.g.,  the 
ability  to  deal  with  large  numbers  of 
potential  access  classes)  are  important, 
but  are  not  DBMS-specific  problems  and  are 
currently  being  explored  in  other  contexts. 

In  particular,  untrustod  algorithms  for 
accessing  and  manipulating  complex  data 
structures  containing  data  of  varying 
sensitivity,  linked  into  a  complex  semantic 
network,  have  not  previously,  to  our 
knowledge,  actually  been  implemented  using 
untrusted  processes  executing  on  top  of  a 
genuine  security  kernel.  At  the  time  the 
demonstration  was  dooigned,  it  seomod 
of  greatest  engineering  importance  to 
demonstrate  the  feasibility  of  such 
algorithms. 

The  importance  of  actually  implementing 
such  algorithms  on  a  genuine  security 
kernel,  is  that  one  may  be  sure  that  no 
hidden  assumptions  or  programming 
"workarounds"  invalidating  the  design  have 
been  introduced  into  the  demonstration 
code,  thereby  gaining  a  high  degree  of 
confidence  that  the  alnurithmr;  and  ideas 
being  demonstrated  arc  valid. 

Our  criterion  of  succos:  for  mooting  this 
goal  wo  defined  as  the  ability  to 
demonstrate  the  central  features  that 
differentiate  the  entity-relationship  data 
model  from  other  data  models:  namely,  its 
pi euontatiorc  to  the  user  of  a  "reference” 
from  one  item  to  another  (rather  than  the 
implicit  linking  of  data  records  by  means 
of  common  data  values),  and  its  ability  to 
present  polyinstantiation  in  a  natural  way 
as  an  attribute  with  multiple  values 
(rather  than,  as  nesdad  for  the  multilevel 
relational  model,  by  introducing  additional 
tueles  with  rc.  Heated  data  in  the  norr- 
pol '/instantiated  fie.'  s).  Thus,  although 
only  a  subset  of  the  Data  model  was 
supported,  it  was  that  subset  that  includes 
the  core  concepts  of  the  data  model 
(entities,  f  .ta  representing  relationships 
between  enl  tties,  and  the  use  if  references 
to  link  together  data  items)  and  that 
distinguish  it  from  the  relational  model. 


The  remainder  of  the  document  is  divided 
into  the  following  sections.  The  section 
entitled  "Functional  Architecture"  provides 
an  overview  of  the  complete  system.  The 
section  entitled  “User  View"  summarizes  the 
operations  and  capabilities  of  the 
demonstration  from  the  users'  point  of 
view.  The  section  entitled  "DBMS  Modules" 
describes  the  database  management  modules 
themselves  in  enough  detail  to  provide  a 
basic  understanding  of  how  data  of 
different  access  classes  is  distributed 
into  physical  segments  of  the  right  access 
class  and  efficiently  re-assembled  in 
response  to  user  queries.  The  final 
section  contains  our  conclusions. 


2.  Functional  Architecture 

The  demonstration  was  targeted  for  a 
single-processor  Gemini  system  running  the 
GEMSOS  Mandatory  Security  Kernel, 
configured  with  a  single  user's  terminal. 

The  demonstration  was  developed  in  the 
(untrusted)  Unix  V  programming  environment 
running  on  Gemini  hardware.  Although  this 
is  now  the  standard  programming  environment 
provided  with  Gemini  systems  for  the 
development  of  GEMSOS  applications,  at  the 
time  the  demonstration  was  implemented  the 
Unix  V  environment  was  still  under 
development  (in  fact,  our  project  was  the 
first  "user"  of  the  Gemini  Unix  V 
environment. )  AS  the  work  necessary  to 
provide  the  full  run-time  support  needed 
for  C  programs  in  the  GEMSOS  environment 
was  in  progress  at  the  time  the 
demonstration  was  implemented,  the 
demonstration  software  includes  some 
components  that  would  now  bo  unnecessary 
because  their  functionality  is  available  in 
the  form  of  run-time  library  functions, 

As  an  established  goal  of  the  demonstration 
was  to  embed  the  DBMS  human  interface  in 
the  context  of  a  realistic  "trusted" 
interface  managing  logon/logout,  trusted 
path  interactions,  and  so  on,  a  relatively 
large  subset  of  the  demonstration  software 
is  devoted  toward  providing  this 
functionality.  As  the  DBMS  is  actually 
executed  by  genuinely  untrusted  subjects, 
much  of  this  TCB  functionality  is  "real" 

1  although  not  meeting  the  rigorous  software 
engineering  standards  expected  for  a  Claus 
A1  or  B3  system),  in  the  sense  that  a 
complete  environment  must  be  maintained 
that  allows  the  DBMS  subjects  to  execute 
without  trust.  For  example,  the  terminal 
port  had  to  be  configured  as  a  single- level 
device  (i.o.,  not  capable  of  associating 
labels  with  input-output  data)  wi th  a 
multilevel  range  (as  both  SECRET  and  TOP 
SECRET  sessions  must  be  available  from  at 
the  torminal.  ) 

Because  all  interactions  with  the  terminal 
are  mediated  by  a  genuine  socurity  kernel , 
and  we  needed  to  be  able  to  have  the 
terminal  place  its  input  data  in  either  a 
SECRET  or  TOP  SECRET  input  buffer 
(depending  upon  current  session  levol )  so 
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that  inter-process  communication  with  the 
currant  untrusted  DBMS  would  work,  the 
correct  labeling  of  the  terminal  port  could 
not  be  "faked".  Similar  considerations 
pervaded  the  design  of  the  “supporting 
environment"  for  the  DBMS,  and  for  all 
practical  purposes,  this  environment  may  be 
regarded  as  a  "real"  TCB  from  a  functional 
point  of  view.  Although  the  pragmatic 
requirement  to  develop  a  "mini-TCB"  for  the 
security  kernel  was  not  specifically  DBMS- 
specific  work,  it  proved  valuable  in 
allowing  the  resulting  demonstration  to  be 
used  to  demonstrate  various  issues 
concerning  trusted  path,  login,  and  session 
level  changes  as  a  side  benefit. 


2 . 1  Process  and  Subject  Structure 

The  demonstration  is  implemented  using  four 
processes.  They  are: 

•  an  initial  process  ( in  execution  as 
the  kernel  comes  out  of 
initialization); 

•  a  (trusted)  TCB  process,  which  manages 
tho  terminal,  provides  input/output 
services  to  the  DBMS  processes,  and 
manages  all  direct  user  interaction 
witli  the  TCB  (o.g.,  iox  logon/ logofi  ) ; 

•  an  (untrusted)  SECRET  DBMS  process, 
which  provides  usnr  access  to  tho 
database  during  SECRET  sessions,  and 

«  an  (untrusted)  TOP  SECRET  DBMS 

process,  which  provides  use.  access  to 
tire  database  during  TOP  SECRET 
sessions . 

Both  the  initial  and  TCB  processor,  exist 
for  the  lifetime  of  tho  demonstration 
(i.e.,  from  tho  time  tire  system  is  booted 
to  the  time  it  is  turned  olf.)  Tho  SECRET 
and  TOP  SECRET  processes  exist  only  tor 
the  liietimo  or  an  untrusted  session  (i.e., 
from  the  time  tho  user  requests  such  a 
session  to  tho  time  tho  "secure  attention 
key"  is  pressed).  Although  their  stacks, 
code,  and  data  segments  are  reused, 
logically  when  a  new  SECRET  session  is 
begun,  a  now  SECRET  process  is  begun:  tire 
previous  SECRET  process  (II  there  was:  turn  I 
was  actually  terminated  at  the  end  of  tho 
last  SECRET  session. 

Tho  initial  process  is  ossontial ly  a  loader 
setting  up  the  initial  segment  structure  in 
main  memory  for  the  remainder  of  the  system 
and  spawning  tiro  TCB  process,  then 
deactivating.  It  will  not  bo  described  in 
lurther  detail  hero. 

The  TCB  process  is  ttustod  over  tho  range 
SECRET  to  TOP  SECRET.  Tiro  TCB  process 
attaches  and  controls  tho  terminal  during 
the  lifetime  of  tho  system:  all  I/O 
requests  from  an  active  untrusted  process 
ore  served  by  tho  TCB  process  using 
interprocess  communication  and  shared 
buffers  of  tho  appropriate  sensitivity. 
Between  untrusted  sessions  tho  TCB  process 


provides  a  direct  interface  to  the  user  in 
order  to  manage  logons,  logoffs,  and 
requested  changes  in  session  level.  When 
the  user  requests  an  untrusted  session,  the 
TCB  process  creates  a  child  process  of  the 
requested  level  (consistent  with  the  user’s 
clearance)  and  acts  as  an  I/O  server  for 
the  child  process.  When  the  user  presses 
the  secure  attention  key  this  is  detected 
by  the  TCB  process,  which  orchestrates  an 
orderly  shutdown  of  the  child  process 
before  returning  to  the  user  for  a  trusted 
interaction. 

The  untrusted  session  processes  (whether 
SECRET  or  TOP  SECRET)  ere  event-driven 
transaction  processors,  providing  complete 
access  (consistent  with  session  level)  to 
that  portion  of  the  database  the  user  is 
authorized  to  view  and/or  update.  Both  the 
SECRET  and  TOP  SECRET  processes  execute 
exactly  the  same  code:  the  sensitivity 
level  of  the  process  itself  is  available  at 
run-timo  as  on  entry  parameter  to  tho 
process.  Although  the  untrusted  processors 
use  this  information  to  "navigate"  through 
the  usable  segments  of  the  database,  they 
are  not  responsible  in  any  way  for 
enforcing  ttio  accessibility  of  data.  if, 
for  instance,  the  SECRET  untrusted  process 
attempted  (erroneously  or  maliciously)  to 
access  a  segment  containing  TOP  SECRET 
data,  the  underlying  security  kernel  would 
simply  refuse  .‘j  request.  (In  fact,  a 
fair  amount  of  debugging  time  consisted  of 
determining  why  such  a  trap  had  occurred  and 
modifying  the  untrusted  piocuss  code  to 
remove  tho  offending  request.) 

Terminal  1 nput/output  requests  are  passed 
to  the  TCB  process  for  service  when  nooded. 
The  result  oi  any  request  tor  service 
(whothei  input  or  output)  may  be  an 
indication  iiom  ihe  TCB  that  the  trusted 
path  was  invoked  --  in  effect,  notification 
co  shut  down.  When  this  happens,  the 
untrusted  process  swaps  the  database  back 
vo  secondary  storage  and  conducts  an 
orderly  shutdown.  GEMSOS  provides  tire 
mechanisms  required  for  handshaking  between 
child  and  parent  to  coordinate  process 
termination.  Although  tho  untrusted 
process:  lias  responuibi  lity  for  helping 
perform  an  orderly  termination  of  itself, 
failure  to  meet  these  i  osponsi  hi  1  it  i  os;  are 
not  insecure  (they  load,  at  worst,  to  a 
denial  of  sorvj.ee  or  loos  of  data.)  Once 
trusted  path  has  been  Invoked,  the  TCB 
process  will  not  perform  1/0  until  the 
shutdown  is  complete. 


3.  User  View 

In  this  section,  we  present  a  brief  summary 
of  tiro  view  of  data  and  human  interface 
presented  to  users;  by  the  demonstration. 
Although  many  viewer’s  of  the  demonstration 
(who  have  never  actually  operatod  a  high- 
assurance  TCB)  found  the  operation  of  the 
"trusted  path"  witli  regard  to  boot  operator 
authentication,  user  login/logout  and 
authentication,  and  session-level 
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negotiation  fairly  interesting,  only  the 
capabilities  presented  to  the  user  during 
an  untrusted  DBMS  session  will  be 
described,  as  it  is  these  capabilities  that 
are  central  to  the  demonstration  goals. 

3.1  Data  Schema 


As  previously  discussed,  the  schema  for  the 
data  managed  by  the  demonstration  is  not 
modifiable.  Three  types  of  entities 
(ordnance,  aircraft,  and  city)  and  two 
types  of  relationships  between  entities 
( aircraft-carries-ordnance  and  aircraft- 
attacks-city )  are  supported.  The  data 
schema  (presented  in  an  ad  hoc  data 
definition  language)  is  detailed  in  the 
Figure  1. 

Although  the  schema  is  relatively  self- 
explanatory,  a  few  words  about  the  entity- 
relationship  data  model  seem  in  order.  An 


define  entity 
primary  key 
attribute 
attribute 
end  AIRCRAFT 


type  AIRCRAFT 
SIDE  NUMBER 
CLASS 
PILOT 


define  entity  type  ORDNANCE 
primary  key  ID 
attribute  EXPLOSIVE 
attribute  TYPE 
end  ORDNANCE 


define  entity 
primary  key 
attribute 
attribute 
attribute 
end  CITY 


type  CITY 
NAME 

POPULATION 

LATITUDE 

LONGITUDE 


define  relationship  ARMED-WITH 
role  AIRCRAFT 

role  ORDNANCE 

attribute  NUMBER 

end  ARMED-WITH 

define  relationship  ATTACKS 
role  AIRCRAFT 

role  CITY 

attribute  DATE 

end  ATTACKS 


Figure  1 .  Data  Schema 

"entity"  is  meant  to  represent  an  "object" 
(real  or  abstract)  with  a  unique  name  (used 
much  as  is  a  primary  key  in  queries)  and 
some  number  of  attributes.  In  the 
multilevel  version  of  the  data  model,  we 
allow  each  attribute  to  be 
polyinstantiated;  that  is,  different 
values  may  exist  in  the  database  for  a 
given  attribute  for  an  entity, 
corresponding  to  different  sensitivities. 
(The  name  of  an  entity  is  always  understood 
to  implicitly  contain  a  sensitivity  —  so 
there  may  be  distinct  entities  with  the 
same  name  in  the  database,  at  different 
access  classes,  as  well.) 


A  "relationship"  is  meant  to  represent  the 
association  of  one  distinct  entity  with 
another.  In  our  version  of  the  data  model, 
attributes  may  be  associated  with  instances 
of  relationships,  as  well.  Each  particular 
instance  of  a  relationship  has  its  own 
sensitivity  (that  of  the  subject  inserting 
it  into  the  database),  and  its  attributes 
may  be  polyinstantiated.  Thus,  the 
collection  of  relationship  instances  a  user 
will  see  as  existing  in  the  database  will 
depend  upon  the  session  level  the  user  has 
specified.  The  relationship  instance  is 
uniquely  defined  by  the  particular  entities 
it  refers  to:  thus,  even  though  there 
might  be  two  entities  with  the  same 
apparent  name  (because  of 
polyinstantiation),  internally  a  given 
relationship  instance  will  refer  to  just 
one  of  them.  (This  is  rather  more 
convenient  than  the  analogous  case  for  the 
relational  model,  where  data  is  "linked" 
only  be  means  of  common,  stored  data 
values. ) 

The  human  interface  presented  to  the  user 
is  screen-oriented  and  interactive. 
Essentially,  the  user  may  insert  or  update 
individual  records  (for  a  single  entity  or 
relationship  instance)  or  cause  the  entire 
visible  contents  of  a  whole  entity  or 
relationship  type  to  be  printed  on  the 
screen  at  once.  Data  may  only  be  updated 
(and/or  inserted)  at  the  user's  current 
session  level:  if  the  user  attempts  to 
update  an  attribute  at  a  lower  level,  the 
attribute  is  polyinstantiated  instead. 

A  typical  display  that  might  exist  for  a 
user  cleared  to  TOP  SECRET,  and  in  a  TOP 
SECRET  session,  when  the  AIRCRAFT  table  is 


printed  is 

shown  in  Figure 

2. 

AIRCRAFT 

Session  Level : 

TOP  SECRET 

|  Side  Nr. 

|  Class  | 

Pilot  | 

|  304  (S) 

!  B-52  (S)  | 

Kelly  (S)  | 

|  320  (TS) 

|  Stealth  (TS)  | 

O'Hara  (TS)  | 

j  327  (S) 

J  B-52  (S)  1 

1  Stealth  (TS)  | 

Murphy  (S)  | 

(a)  in  TOP  SECRET  sea 

ision 

AIRCRAFT 

Session  Level : 

SECRET 

|  Side  Nr. 

|  Class  | 

Pilot  | 

|  304  (S) 

|  B-52  (S)  | 

Kelly  (S)  | 

|  327  (S) 

|  B-52  (S)  | 

Murphy  ( S )  | 

(b)  In  SECRET  session 
Figure  2.  Initial  Views  of  AIRCRAFT 
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These  views  are  what  we  would  intuitively 
expect:  the  SECRET  view  of  the  database 


looks  like  the  TOP  SECRET  view,  but  with 
all  of  the  TOP  SECRET  data  filtered  out. 

It  is  emphasized,  however,  that  what  is 
really  going  on  is  that  the  (untrusted) 

DBMS  is  assembling  this  view  based  upon  all 
of  the  AIRCRAFT  data  it  can  find  --  it  is 
the  security  kernel  underneath  that  makes 
it  impossible  for  the  DBMS  to  find  any  TOP 
SECRET  data  during  a  SECRET  session, 
because  that  data  is  stored  in  top  SECRET 
physical  segments.  Thus,  with  high 
assurance,  there  is  no  way  the  SECRET  view 
can  encode  or  allow  the  value  of  any  TOP 
SECRET  data  to  be  inferred  --  nor  does  the 
DBMS  code  itself  need  to  be  analyzed  in 
order  to  know  this. 

The  views  presented  in  the  last  figure  also 
illustrate  a  few  points  of  interest. 

Flight  304  represents  a  SECRET  flight  -- 
that  is,  all  of  the  data  about  this  flight 
was  entered  by  some  user  during  a  SECRET 
section.  Similarly,  Flight  320  is  a  TOP 
SECRET  flight.  Flight  327  is  more 
interesting:  at  a  SECRET  level,  the  Flight 

appears  to  be  an  ordinary  SECRET  Flight. 
However,  at  a  TOP  SECRET  level  (viewable 
only  to  users  with  TOP  SECRET  or  greater 
clearances)  we  see  that  the  “Class" 
attributed  is  polyinstantiated:  that  the 
aircraft  class  is  "B-52'1  is  ( apparently )  a 
"cover  story":  the  aircraft's  real  class 
is  "Stealth"  --  a  TOP  SECRET  datum.  This 
database  state  could  be  reached  in  the 
following  order  by  a  user  cleared  TOP 
SECRET.  First,  the  user  asks  for  a  SECRET 
session  and  enters  the  SECRET  record  using 
the  "cover"  data.  Then,  that  user  obtains 
a  TOP  SECRET  session  and  enters  the  TOP 
SECRET  information  as  an  update  to  the 
SECRET  record.  The  database 
polyinstantiatas  the  value  (because  it  is 
untrustod,  it  would  be  unable  to  modify  or 
delete  the  SECRET  attribute  in  any  event.) 

Lot  us  now  suppose  that  there  is  a  change 
of  pilots  for  Flight  327  from  Murphy  to 
O'Neil.  A  user  cleared  SECRET  is 
responsible  for  entering  this  update.  That 
user  (who  has  no  idea  that  there  is  TOP 
SECRET  data  associated  with  this  flight) 
obtains  a  SECRET  session  and  makes  the 
update  in  the  expected  way  --  by  calling  up 
the  rocord  for  Flight  327  and  changing  the 
pilot  data.  The  new  view  of  the  record  is 
as  shown  in  Figure  3  for  SECRET  and  TOP 
SECRET  users. 

Tho  most  important  point  to  note  is  that 
although  tho  data  modified  is  SECRET,  the 
change  is  instantly  propagated  to  the  view 
of  data  given  to  tho  TOP  SECRET  user.  The 
point  is  that  we  are  dealing  not  with 
replicated  data,  but  with  one  version  of 
delta  properly  arranged  by  access  class 
being  integrated  dynamically  by  the  DBMS  in 
response  to  queries.  It  is  our  belief  that 
to  bo  useful,  a  "multilevel"  DBMS  must  have 
exactly  this  sort  of  semantics  on  update: 
the  ability  for  a  "multilevel  record"  as 
viewed  by  a  high-level  user  to  respond 
"instantly"  to  changes  made  to  its  lower- 
level  components. 


AIRCRAFT  Session  Level:  TOP  SECRET 


|  Side  Nr. 

|  Class 

|  Pilot  | 

1  327  (S) 

1  B-52  (S) 

I  O'Neil  (S)  1 

|  Stealth  (TS) 

1  1 

(a)  In 

TOP  SECRET  session 

AIRCRAFT 

Session 

Level:  SECRET 

|  Side  Nr. 

|  Class 

|  Pilot  | 

|  327  (S) 

|  B-52(S) 

|  O'Neil  | 

(b)  In  SECRET  session 
Figure  3.  Updated  views  of  Flight  327 


Similar  examples  drawn  from  a  relationship 
type  will  not  be  given  here,  as 
relationship  data  and  modifications  to  it 
work  in  a  similar  way. 

4.  DBMS  Module  Descr '  ~  ..ions 

In  this  section,  the  heart  of  tha 
demonstration  system  (the  untrusted 
application  modules  responsible  for 
actually  maintaining  and  retrieving 
information  from  the  database)  are 
described,  essentially  in  "bottom  up" 
order.  Details  concerning  those  untrusted 
modules  responsible  for  providing  I/O  and 
high-level  terminal  services,  as  well  as 
modules  of  the  TCB  emulation,  are  available 
in  the  technical  report  describing  thu 
system,  [5]. 

4 . 1  Kernel  Interface  Module 

The  lowest  level  module,  called  the  Kernel 
interface  Modulo,  hides  much  of  the  detail 
of  how  GEMSOS  segments  are  named  and 
accessed  from  higher  level  modules.  The 
primary  goal  in  ciesigning  this  modulo  was 
to  provide  a  means  for  performing  unit 
tests  of  the  remainder  of  tho  DBMS  in  the 
UNIX  environment,  as  project  contention  for 
the  target  development  machine  was 
relatively  high.  The  module  represents  the 
database  as  a  small  number  (eight)  of 
fixed-length,  numbered  segments.  Functions 
are  providod  to  open,  close,  read,  and 
write  each  segment.  The  UNIX  version  of 
the  module  maps  each  segment  to  a  file. 
"Reading"  a  segment  means  that  the  file  is 
copied  into  a  'local  array  and  the  physical 
address  of  the  array  passed  to  the  invoking 
function.  The  GFJMSOS  version  of  the  module 
"opens"  a  segment  by  making  it  known 
(translating  the  number  into  a  proassigned 
pathname)  and  “reads"  it  by  swapping  it  in 
and  returning  its  address.  All  of  the 
segments  are  "opened"  and  "read"  by  the 
main  program  during  the  initialization 
phase  of  the  process,  and  "written"  and 
"closed''  when  the  process  is  terminated. 
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4 . 2  EN  Table  Manager 

The  next  layer  of  the  DBMS  software  manages 
tables  (stored  in  segments)  representing 
entities  and  their  names  (keys). 

Logically,  there  is  a  separate  "entity 
table"  (E  Table)  for  each  access  class. 

The  E  table  may  be  thought  of  as  a  table  of 
descriptors,  with  one  descriptor  for  each 
entity  currently  in  the  database.  The 
doscriptoi.  for  a  given  entity  is  stored,  of 
course,  in  the  particular  E  Table  for  the 
access  class  of  the  subject  that  added  the 
entity  to  the  database,  so  any  entities 
add<'d  by  a  SECRET  subject  are  represented 
by  dosi'i  i  |'-ti 'i  s  in  the  SECRET  E  Table,  while 
any  onl.  Mini  added  by  a  TOP  SECRET  subject 
are  repu  ..ml  ml  by  descriptors  in  the  TOP 
SECRET  E  Table. 

The  ".internal  identifier  "  for  an  entity  has 
two  components:  the  access  class  of  the  E 
Table  i.t  is  found  in,  and  the  index  into 
the  table  for  the  entity's  descriptor. 
Throughout  the  implementation,  the  numerals 
{!  and  1  won)  used  to  encode  the  two  access 
cl  or- SOS  supported,  SECRET  and  TOP  SECRET, 
respect  i  ve.ly .  Given  tho  pair  <accoss 
class,  index.',  finding  the  actual  record 
leprojrnt.ing  a  particular  entity  is 
straightforward.  (for  a  SECRET  process,  a 
"unitjuc  .id"  of  the  form  <TOF  SECRET,  x>  is 
not  useful  as  attempting  to  access  the  TOP 
SECRET’  table  wil  t  result  in  a  trap.  Each 
I  unction  in  the  OHMS  is  written  to  check 
Llie  validity  of.  input  paramo tors,  including 
access  class,  to  avoid  sucli  traps.  ) 

Emil  E  Table  descriptor  contains  two 
fields.  Thu  first:  in  a  numeral,  encoding 
tho  type  of  the  entity.  Tho  second  is  .ur> 
index  to  an  N  Table  descriptor. 

There  are  also  two  N  Tables,  one  for  SECRET 
and  one  ior  TOP  SECRET.  Each  N  Table  entry 
is  a  descriptor  representing  tile  (human- 
readable)  nemo  of  an  entity.  (from  the 
point  of  view  of  the  data  model,  the  name 
of  an  entity  .is  the  value  of  a  designated 
property  of  the  entity,  depending  on  its 
typo.)  Each  tl  Table  descriptor  contains  two 
fields:  tho  name  (key)  value  itself,  and 

an  index  to  the  E  Table  record  for  tho  same 
on  lily. 

Taken  together,  the  E  table  and  N  table 
records  for  a  given  entity  may  be  thought 
of  as  doubly- 1  inked  parts  of  a  single 
logical  record.  This  whole  record,  as  a 
consequence  ot  the  data  model l  definition, 
h.;a  a  uniform  access  class  so  those  parts 
ran  be  stored  in  tho  same  physical  segment. 
Knowing  Where  either  part  in,  the  other 
pint  can  wui.sk  ly  bo  found  by  following  a 
link. 

Tho  motivation  tor  separating  an  entity 
descriptor  into  two  physical  parts  was  tho 
following:  downward  references  to  some 

entity  records*  will  bo  made  (for  Instance, 
TOP  .SECRET  properties  for  SECRET  entities 
may  he  cinLofi’d).  Tho  records  representing 
.•inch  properties,  which  must  be  stored  in  a 
TOP  SECRET  pnyuic.il  segment,  wil.l  contain 


an  <access  class,  E  Table  index>  reference 
to  the  particular  E  Table  record 
representing  the  entity  having  the 
property.  No  SECRET  process  can  be  allowed 
to  move  the  E  Table  descriptor  from  one 
place  to  another  within  tire  SECRET  E 
Table,  because  that  would  invalidate  the 
downward  reference.  There  is  no  way  that 
the  SECRET  process  could  modify  the 
downward  reference  to  reflect  a  new 
location  for  tho  E  Table  descriptor, 
because  the  SECRET  process  cannot  read  or 
write  a  TOP  SECRET  table.  Therefore,  the 
E  Table  descriptors,  once  entered,  are 
never  moved:  they  serve  as  stable  targets 
for  downward  references  to  the  entity  they 
represent . 

On  the  other  hand,  in  order  to  provide  for 
the  rapid  location  of  entitles  by  (human- 
readable)  name,  somo  sort  of  index  must  be 
provided  into  the  E  Table.  This  is  the 
function  of  the  N  Table.  Its  records  are 
maintained  in  alphabetical  order  by  name. 

(A  more  sophisticated  indexing  technique 
would  he  used  in  a  genuine  DBMS,  but  the 
principle  is  the  same. )  That  is,  as  new 
entities  are  entered,  the  N  Table  is 
rearranged  and  both  the  forward  and 
backward  links  to  the  15  table  are  updated 
as  required.  This  is  always  possible 
because  the  two  parts  of  tho  entity  record 
(a  motionless  one  in  the  E  table,  and  a 
movable  one  in  the  N  table)  are  always  of 
tho  same  access  class,  if  a  process  is 
allowed  to  move  the  N  table  record,  it  is 
allowed  to  update  the  E  table  record  to 
match  the  new  position  in  the  N  table. 

Functions  provided  to  maintain  and  use  the 
E  and  N  Tables  (in  concert)  include  a 
function  to  add  a  named  entity,  a  function 
that  locates  an  entity  given  its  access 
class  and  name,  and  a  function  that  locates 
an  entity  given  J.t3  access  class  and  E 
Table  index. 

4 . 3  Relationship  .Tables 

The  next  layer  of  the  DBMS  software 
implements  "Relationship  Tables",  or  K 
Tables.  As  for  E  and  N  Tables,  there  are 
two  R  Tables,  one  for  SECRET  relationships 
and  one  for  TOP  SECRET  relationships.  Each 
relationship  is  represented  by  a  record 
containing  an  integer  representing  tho  typo 
of  the  relationship,  and  a  reference  to 
each  of  the  two  entities  related.  Each 
such,  reference  has  two  parts:  an  access 
class  code  and  an  E  Table  Index.  The 
access  class  is  required  because  a 
reference  may  bo  downward:  it  may  bo  that 
a  TOP  SECRET  relationship  exists  that 
relates  a  SECRET  entity  to  another  entity. 
Without  tho  access  class  field,  it  would 
not  bo  possible  to  tell  whether  the  E  Table 
reference  in  a  relationship  was  to  be 
applied  to  the  SECRET  (5  Table  or  tho  TOP 
SECRET  E  Table. 

As  on  implementation  choice,  no  index  was 
created  for  relationships  as  the  technique 
had  already  been  demonstrated  for  entities. 
One  could  easily  conceive  of  tables 
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indexing  the  R  Table  by  their  effective 
keys  (the  two  references),  just  as  the  N 
tables  serve  as  indexes  .into  the  E  tables, 
that  would  function  in  much  the  same  way. 
Functions  provided  for  manipulating  R 
Tables  include  one  to  add  a  new 
relationship,  and  to  locate  a  relationship 
given  its  access  class  and  references. 

4 . 4  Property  Tables 

Entities  in  the  demonstration  database  have 
non-naming  properties  as  well  as  names,  and 
relationships  have  properties  as  well.  For 
the  demonstration  schema,  polyinstantiat.ion 
of  non-naming  properties  ar.d  properties  of 
relationships  is  allowed:  that  is,  there 
may  be  both  SECRET  and  TOP  SECRET  values 
for  a  given  non-naming  property  of  a  SECRET 
entity,  or  for  a  property  of  a  SECRET 
relationship . 

Non-naming  properties,  or  properties  of 
relationships,  were  uniformly  stored  in 
one  of  two  Property  Tables,  or  P  Tables. 

The  approach  taken  was  "brute  force”:  a 
record  was  preallocated  corresponding  to 
each  possible  entry  in  each  E  or  R  table 
for  each  access  class.  As  non-naming 
properties  were  entered,  thair  values  were 
simply  stored  in  the  appropriate  slot.  A 
more  compact  representation  would  have 
involved  explicit  references  to  the  entity 
or  relationship  having  the  property 
(possibly  a  downward  reference),  and  an 
index  into  the  property  table  so  that  the 
properties  of  a  given  entity  or 
relationship  could  be  located  quickly. 

4 . 5  HOMS  Inter £  apo..  Modulo 

The  topmost  layer  of  the  DBMS  consisted  of 
an  interface  module  that  mapped  the  defined 
programming  interface  for  a  selected  subset 
of  the  entity-relationship  data  model  to 
the  appropriate  sequence  of  calls  to  the 
the  EN,  R ,  and  1>  table  managers. 


5.  Summary  and  Conclusions 

It  Is  our  belief  that  the  demonstration 
meets  or  exceeds  all  of  its  objectives.  In 
particular,  it  demonstrates  and  exercises 
techniques  for  creating  and  maintaining 
downward  references  from  one  data  olement 
to  another  of  lower  sensitivity,  and  the 
provision  of  high  apparent  granularities  of 
classification  by  storing  small  data 
elements  in  large  repositories. 

(It  must  be  emphasized  that  intrinsic  to 
this  approach  is  that  the  security 
indicators  presented  to  the  users  are  not 
safe  with  respect  to  downgrading. )  All  of 
the  data  presented  in  a  TOP  SECRET  session 
must  be  treated  as  TOP  SECRET.  However, 
tills  is  not  as  cumbersome  a  property  as 
may,  at  first,  appear.  If,  for  instance, 
a  user  with  a  TOP  SECRET  clearance  is 
browsing  the  database  with  a  session  level 
of  TOP  SECRET,  and,  as  the  rosult  of 
issuing  a  query,  decides  that  a  "sanitized11 
version  of  that  query  should  bo  prepared 


for  release  at  a  SECRFT  leval,  the  user  can 
simply  press  the  "Secure  Attention"  key  to 
negotiate  a  session  level  of  SECRET  and 
re-issue  the  desired  query.  (It  might  be 
noted  that  there  is  no  requirement,  even  in 
the  demonstration,  to  logout  and  login 
again,  as  the  TCB  is  designed  to  "remember” 
the  clearance  of  the  currently  loggecl-in 
user. ) 

The  demonstration  also  serves,  in  our 
opinion,  as  a  proof  of  concept  that  an 
adequate  degree  of  functionality  for  a 
multilevel  DBMS  can  be  attained  by 
implementing  the  DBMS  as  an  untrusted 
application  on  an  existing  TCB.  The  major 
criterion,  we  suggest,  that  a  "multilevel 
DBMS"  must  meet  to  be  useful  is  that  a  user 
should  be  able  to  view  all  of  the  data 
classified  at  the  user's  session  level  or 
below,  and  that  it  must  be  possible  to 
relate  high-sensitivity  data  with  data  of 
lower  sensitivity  in  such  a  way  that  when 
the  lower  sensitivity  data  is  modified, 
these  modifications  are  reflected  in  the 
higher  level  view  of  the  related  data. 

For  instance,  if  a  SECRET  data  item  (say  a 
Flight  with  a  particular  Pilot)  has  a  TOP 
SECRET  property,  (say  its  cargo),  and  the 
SECRET  item  is  modified  (say  the  Pilot  is 
changed),  the  change  ought  to  be  reflected 
in  the  TOP  SECRET  view  ( the  TOP  SECRET 
cargo  ought  to  remain  associated  with  the 
modified  SECRET  item).  This  requirement 
precludes  implementations  that  make 
redundant  copies  of  low  sensitivity  data 
for  high  sonsitivity  subjects  but  cannot 
then  maintain  those  copies.  The 
demonstration  is  specifically  designed  to 
show  that  meeting  those  requirements  with 
an  untrusted  DBMS  is  possible. 

The  following  observations  resulting  from 
our  experience  in  implementing  the 
demonstration  might  also  be  ol  general 
interest. 

•  The  implementation  effort  involved 
programmers  not  familiar  with  the 
implementation  and  design  of  trusted 
systems.  By  designing  the  DBMS  os  an 
application  to  be  built  on  top  of  a 
DBMS,  this  lack  of  specialized 
expertise  was  finessed.  In  effect, 
the  use  of  a  security  kernel  aa  a 
"virtual  machine"  transforms  tire 
problem  of  designing  and  implementing 
a  provably  secure  system  into  the  much 
easier  problem  of  designing  and 
implementing  an  "ordinary"  application 
that  will  function  as  spocifiod. 
Working  within  the  limitations  of  the 
Basic  Security  and  Confinement 
properties  was  not  a  great  deal  more 
difficult  than  working  within  the 
limitations  imposed  by  a  run-time 
environment  that  does  dynamic  bounds 
checking  on  arrays. 

•  It  also  was  not  particularly  difficult 
finding  specific  data  structure  and 
algorithmic  solutions  to  the  problems 
posed  by  the  demonstration 


177 


requirements  (e.g.,  how  to  represent  a 
"downward  reference").  The  knowledge 
that  the  use  of  s  "trusted  process"  to 
perform  any  critical  functions  was 
forbidden  was  a  useful  and  immediately 
productive  discipline. 

•  The  most  troublesome  aspect  of  the 
design  and  implementation  was  in  the 
area  of  human  interface  design.  This 
we  attribute  to  a  fairly  ambitious 
desire  to  provide  a  screen-oriented, 
event-driven  interface  with 
insufficient  thought  given  to  its 
abstract  specification.  The  resulting 
interface,  while  reasonably  nice  for 
this  particular  demonstration,  does 
not  scale  up  in  any  reasonable  way  to 
support  for  large  numbers  of  potential 
access  classes. 

•  Polyinstantiation  proved  easy  to 
implement  (you  just  let  it  hopper)  but 
hard  to  deal  with  from  a  DBMS 
application  point  of  view. 

Applies  cion  logic  that  deals  with 
polyinstantiated  properties  on  a 
case-by-case  basis  is  difficult  to 
write,  particularly  for  a  semantically 
"rich"  data  model  such  as  the  entity- 
relationship  modal.  This  suggests 
that  high  level  operators  that  deal 
with  potentially  polyinstantiated 
items  and  properties  need  to  bo 
devised  for  use  by  applications.  The 
generalization  of  report  generators 
and  screen  generators  to  cope  with 
polyinstantiated  values  is  likely  to 
bo  quite  difficult. 
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Abstract 

A  distributed  architecture  for  a  multilevel  secure 
database  management  system,  based  on  the  distri¬ 
buted  architecture  developed  at  the  1982  Air  Force 
Summer  Study  on  "Multilevel  Data  Management 
Security",  is  presented  and  described  in  terms  of 
how  it  implements  the  relational  operators.  There 
are  two  notable  aspects  of  this  architecture.  First, 
it  factors  the  effect  of  the  security  class  of  the 
query  into  the  classification  of  derived  data.  This 
allows  tuple  level  labels  to  be  safely  used  for  man¬ 
datory  access  control.  Secondly,  it  provides  reli¬ 
able  tuple  level  labeling  without  requiring  the  rela¬ 
tional  operators  to  be  trusted.  This  makes  this 
architecture  a  suitable  basts  for  a  near-term  solu¬ 
tion  to  multilevel  database  management  using 
existing  DBMS  components  to  implement  the  rela¬ 
tional  operators. 

1.  Introduction 

The  majority  of  the  databases  in  the  Department  of  Defense 
(DOD)  and  the  intelligence  community  ate  computerized. 
These  databases  commonly  contain  data  that  arc  classified  at 
multiple  security  levels  and  must  be  restricted  for  different 
levels  of  user  access.  The  most  common  means  of  restrict¬ 
ing  access  to  these  data  is  to  store  them  in  an  untrusted  data¬ 
base  management  system  (DBMS),  and  operate  the  system 
in  system-high  mode.  In  this  mode,  every  user  is  cleared  to 
the  level  of  the  most  highly  classified  piece  of  information 
in  the  system,  and  all  data  leaving  the  system  are  assigned 
the  highest  classification  until  a  human  reviewer  assigns  the 
proper  classification.  Since  all  users  must  be  cleared  to 
system-high,  the  cost  of  system  operation  and  the  risk  of  a 
security  breach  is  much  greater  than  it  might  be. 

The  1982  Air  Force  Summer  Study  on  "Multilevel  Data 
Management  Security"  made  several  recommendations  on 
the  development  of  multilevel  database  management  sys¬ 
tems  [1].  Group  1  of  the  study  focused  on  near-term 
solutions  to  multilevel  database  security.  One  of  the  recom¬ 
mended  approaches  was  a  Distributed  DBMS  (D-DBMS) 
architecture  that  utilized  one  untrusted  DBMS  per  security 
level  supported.  It  was  recognized  that,  by  employing  phy¬ 
sically  separate,  untrusted  DBMSs,  a  D-DBMS  architecture 
could  provide  a  high  level  of  security  and  performance  in 
the  near-term,  while  lowering  development  costs  and  risk, 


Unisys  is  currently  involved  in  an  effort,  funded  by  the  U.S. 
Air  Force,  Rome  Air  Development  Center  (RADC),  to 
design  a  Multilevel  Secure  (MLS)  DBMS  that  meets  the 
requirements  for  a  Class  B3  trusted  computer  system  [2]. 
Our  approach  is  a  variation  on  the  D-DBMS  approach 
recommended  by  Group  1 .  This  paper  describes  the  Secure 
D-DBMS  (SD-DBMS)  architecture  that  was  developed  as  a 
first  step  in  our  design.  Although  discretionary  security  was 
an  important  consideration  in  the  development  of  this  archi¬ 
tecture,  this  paper  will  focus  primarily  on  the  enforcement 
of  mandatory  security. 

In  this  paper,  it  is  assumed  that  the  reader  is  familiar  with 
the  relational  data  model  [3,4]  and  the  concepts  of  mul¬ 
tilevel  security  [5,6]. 

2.  Security  Classes,  Subjects,  and  Objects 

The  SD-DBMS  is  being  designed  to  support  a  set  of  three 
security  classes.  These  security  classes  can  be  hierarchical 
levels  (e.g„  TOP  SECRET,  SECRET,  and  CONFIDEN¬ 
TIAL),  non-hierarchical  categories  (e.g.,  NATO,  NOFORN, 
NUCLEAR),  or  a  combination  of  the  two.  The  design  can, 
however,  be  easily  extended  to  support  four  or  more  security 
classes.  The  limiting  factor  is  that  the  design  requires  one 
DBMS  per  security  class  supported.  Note  that  the  set  of 
security  classes  does  not  necessarily  form  a  lattice,  as 
described  in  [7],  For  example,  if  the  system  is  configured  to 
support  three  non-hierarchical  categories  (e.g.,  A,  B,  and  C), 
then  data  from  different  categories  cannot  be  mixed  since 
the  result  would  constitute  a  new  (fourth)  security  class. 
The  set  of  security  classes  is  partially  ordered  by  a  relation 
called  dominates.  If  C  t  and  C  2  are  security  classes,  C  j  is 
said  to  dominate  C2  if  and  only  if  the  hierarchical 
classification  of  C  ]  is  greater  than  or  equal  to  that  of  C  2, 
and  the  categories  in  C2  are  a  subset  of  those  in  Cj.  C  t  is 
said  to  strictly  dominate  C2  if  and  only  of  C ;  dominates  but 
is  not  equal  to  C 2- 

Mandatory  security  is  enforced  in  terms  of  subjects  and 
objects.  In  the  SD-DBMS,  subjects  are  assigned  two  secu¬ 
rity  classes  called  a  read  class  and  a  write  class.  A  subject’s 
read  class  must  dominate  its  write  class.  A  subject  is  per¬ 
mitted  to  read  an  object  at  a  particular  security  class  if  the 
read  class  of  the  subject  dominates  the  security  class  of  the 
object.  A  subject  is  permitted  to  write  an  object  at  a  particu¬ 
lar  security  class  if  the  security  class  of  the  object  dominates 
the  write  class  of  the  subject,  and  the  read  class  of  the  sub-, 
ject  dominates  the  security  class  of  the  object.  If  a  subject’s 
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read  class  strictly  dominates  its  write  class,  it  is  said  to  be  a 
trusted  subject. 

When  it  does  not  cause  a  loss  of  generality,  the  discussions 
and  examples  in  this  paper  will  use  the  terms  high  and  low 
to  refer  to  any  two  security  classes  where  the  first  strictly 
dominates  the  second. 

3.  Multilevel  Relations 

The  function  of  the  SD-D13MS  is  to  manage  and  control 
access  to  multilevel  databases,  A  multilevel  database  is 
defined  to  be  a  collection  of  logically  related  multilevel  rela¬ 
tions. 

Definition  3.1:  A  multilevel  relation  R  is  defined 
as  having  two  parts:  a  time-invariant  schema 
R(A  UA2,  :.,An,SC),  where  Al,A2,...,An  are 

attributes  over  some  domains  D  Jt  Z> 2 . ®n<  anc* 

SC  is  an  attribute  over  a  set  of  security  classes  CL; 
and  a  time-varying  set  of  tuples  T,  such  that 
T  cD t  x Z) 2 x  ■  •  •  xDnxCL.  The  set  CL  is 
called  the  range  of  R. 

Note  that  the  schema  for  a  multilevel  relation  includes  a 
security  class  attribute.  For  each  tuple  in  the  relation,  this 
attribute  is  used  to  indicate  the  classification  of  the  data  con¬ 
tained  within  the  tuple.  This  information  is  used  by  the  sys¬ 
tem  to  enforce  mandatory  access  control. 

The  above  definition  permits  tuples  to  be  polyinstivuiated. 
Polyinstantiation  refers  to  the  simultaneous  existence  of 
multiple  data  objects  with  the  same  name,  where  the  multi¬ 
ple  instantiations  are  distinguished  by  their  security  class 
[8,9, 10].  In  the  SD-DBMS,  this  means  that  there  may  be 
two  or  more  tuples  in  a  multilevel  relation  with  the  same 
primary  key.  These  tuples  are  uniquely  identified  by  the 
combination  of  their  primary  key  and  their  security  class. 
Although  it  presents  an  integrity  problem,  polyinstantiation 
must  be  supported  in  an  MLS  DBMS  in  order  to  prevent  the 
appearance,  disappearance,  or  perceived  presence  of  data 
from  being  used  as  an  inference  or  signaling  channel. 

When  a  relational  operator  is  applied  to  one  or  more  mul¬ 
tilevel  relations,  the  result  is  another  multilevel  relation, 
called  a  derived  relation.  An  important  consideration  is  how 
the  tuples  in  a  derived  relation  are  labeled.  One  possible 
approach  is  to  label  each  tuple  at  the  least  upper  bound  of 
the  security  classes  of  the  tuples  that  entered  into  its  deriva¬ 
tion.  For  example,  when  a  tuple  is  selected  or  projected,  its 
security  class  is  unchanged;  when  two  tuples  are  joined,  the 
resulting  tuple  is  labeled  at  the  least  upper  bound  of  the 
security  classes  of  the  original  tuples.  This  is  the  approach 
taken  in  the  SeuView  effort  [9],  However,  as  pointed  out  in 
Appendix  A  of  [9],  these  labels  do  not  accurately  reflect  the 
security  classes  of  parameters  embedded  in  relational 
expressions,  or  the  security  classes  of  data  upon  which  the 
decision  to  evaluate  a  particular  expression  might  have  been 
conditioned.  This  led  the  SeaView  project  to  the  conclusion 
that  tuple  level  labels  arc  inherently  advisory.  Our  conclu¬ 
sion  differs  in  that  we  believe  that  tuple  level  labels  can  be 
perfectly  reliable  if  the  security  class  of  the  query  is  con¬ 


sidered  when  determining  how  to  label  derived  data.  For 
this  reason,  in  the  SD-DBMS  the  query  is  a  labeled  object, 
and  each  tuple  in  a  derived  relation  is  labeled  with  the  least 
upper  bound  of  the  security  classes  of  the  tuples  that  entered 
into  its  derivation  and  the  security  class  of  the  query. 

Since  queries  are  labeled  objects,  there  must  be  a  way  to 
determine  the  security  class  of  a  given  query.  If  the  query  is 
submitted  by  a  untrusted  application  program,  its  security 
class  is  set  to  be  that  of  the  application  (i.e.,  equal  to  its  read 
class  and  write  class).  This  nas  the  effect  that,  for  all 
untrusted  applications,  results  are  returned  at  the  security 
class  of  the  application.  It  should  be  noted  that,  if  there  is  a 
need  for  advisory  labels,  they  can  be  explicitly  stored  in 
relations  as  an  additional  column.  If  the  query  is  submitted 
by  a  multilevel  application,  the  multilevel  application  can 
supply  the  SD-DBMS  with  the  security  class  of  the  query 
(providing  it  falls  within  the  application’s  security  class 
range).  The  correctness  of  these  labels  can  be  verified 
through  an  information  flow  analysis  of  the  application  pro¬ 
gram  [6J. 

An  important  special  case  occurs  when  the  application  is  an 
interactive  user  interface.  In  this  case,  users  enter  queries 
directly.  If  the  interface  is  untrusted,  the  level  of  the  query 
must  be  taken  to  be  the  level  of  the  interface.  If  the  inter¬ 
face  is  trusted  (multilevel),  the  user  can  supply  the  SD- 
DBMS  with  tlte  security  class  of  the  query.  This  would 
require  that  the  interface  include  a  mechanism  that  permits 
the  user  to  reliably  communicate  the  security  class  of  the 
query.  It  is  assumed  that  the  user  is  aware  of  the  security 
class  of  the  query  being  entered.  This  assumption  is  con¬ 
sistent  with  those  made  about  users  of  multilevel  operating 
systems. 

The  above  approach  to  labeling  tuples  is  attractive  for  two 
important  reasons.  First,  it  is  firmly  based  on  an  informa¬ 
tion  flow  model  of  security  (i.e.,  it  accounts  for  information 
flows  that  can  result  from  sequences  of  the  relational  opera¬ 
tors,  parameters  in  relational  expressions,  and  flows  in 
application  programs).  This  allows  tuple  level  labels  to  be 
safely  used  for  mandatory  access  control.  Second,  it  main¬ 
tains  the  important  closure  property  of  the  relational  model 
(i.e..  the  result  of  all  relational  operators  are  muhilevel  rela¬ 
tions). 

4.  SD-DBMS  Abstract  Architecture 

The  SD-DBMS  architecture,  shown  in  figure  4.1,  consists  of 
three  types  of  components:  User  Programs,  the  Data 
Manager,  and  back-end  DBMSs.  A  User  Program  is  a  user 
interface  or  application  program  permitted  to  issue  queries 
against  a  multilevel  database.  User  Programs  can  be  (rusted 
(i.e.,  multilevel)  or  untrusted  (i.e.,  single  level).  Trussed 
User  Programs  are  permitted  to  issue  queries  at  multiple 
security  levels  and  receive  multilevel  results. 

The  Data  Manager  is  a  trusted  component  that  perforins  the 
reference  monitor  functions  in  the  SD-DBMS.  A  reference 
monitor  is  an  abstract  machine  that  mediates  all  accesses  to 
objects  by  subjects  |2J.  In  the  SD-DBMS,  the  suojects  are 
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User  Programs  and  (lie  objects  are  tuples  in  multilevel  rela¬ 
tions  and  user  queries.  The  Data  Manager  component  also 
performs  query  decomposition  and  execution  control  func¬ 
tions.  These  functions,  most  of  which  can  be  implemented 
in  untrusted  code,  are  discussed  in  detail  in  section  5. 

Finally,  the  back-end  DBMSs  are  untrusted  single-level 
relational  DBMSs  used  to  store  and  process  portions  of  the 
multilevel  database.  There  is  one  back-end  DBMS  per  secu¬ 
rity  class  supported  by  the  system. 


Data 

Manager 


Figure  4.1,  SD-DHMS  Abstract  Architecture 

The  SD-DBMS  stores  multilevel  relations  by  horizontally 
partitioning  them  into  single-level  fragments,  which  are  then 
stored  under  the  appropriate  back-end  DBMSs.  When  a 
user  creates  a  multilevel  relation,  the  system  creates  a  sot  of 
single-level  fragments  in  which  to  store  the  relation.  This  is 
done  using  the  following  algorithm. 

Algorithm  4.1:  Given  a  multilevel  relation 
/?(/!,,  A  2,  ....  An,  SC),  with  a  range  CL,  for  each 
security  class  c  e  CL,  create  a  fragment 
RC(,A  j,  Aj, ....  A„)  on  the  back-end  DBMS  with 
security  class  c. 

For  example,  a  multilevel  relation  K  with  a  range  {high, 
low}  would  be  mapped  into  two  fragments,  Ru  h  and  R,ow. 
The  fragment  R>Ujjit  would  be  created  on  the  high  DBMS 
and  used  to  store  the  high  tuples  in  R,  and  the  fragment  R/nw 
would  be  created  on  the  low  DBMS  and  used  to  store  the 
low'  tuples  in  R.  The  multilevel  relation  R  is  part  of  an 
example  multilevel  daiabase,  summarized  in  table  4.1,  that 
will  be  used  in  examples  throughout  this  paper. 


Relation 

Primary  Key 

Range 

Fragments 

R(x,a) 

X 

{low, high} 

^  low ,  ^high 

S(x.b) 

X 

{low, high} 

^l>w ,  ^  high 

M(x,c) 

X 

{low} 

"to* 

Table  4.1.  Example  Multilevel  Database 


To  retrieve  data  front  a  multilevel  database,  subjects  (User 
Programs)  submit  queries  to  the  Data  Manager.  The  Data 
Manager  decomposes  each  query  into  a  sequence  of 
subqueries  that  operate  on  single-level  fragments.  This 
decomposition  is  done  in  such  a  way  that  each  subquery 
produces  a  single-level  result,  and  the  union  of  these  single¬ 
level  results  forms  the  result  of  the  original  query.  To 
decompose  queries  in  this  way  is  not  difficult  since  all  rela¬ 
tional  operators,  except  for  union,  produce  single  level 
results  when  applied  to  single  level  fragments.  The  motiva¬ 
tion  for  this  decomposition  strategy  is  that,  if  the  relational 
operators  always  return  single  level  results,  the  back-end 
DBMSs  that  implement  them  can  be  untrusted. 

Once  a  query  is  decomposed  into  subqueries,  each  of  the 
subqueries  is  executed  on  the  back-etid  DBMS  having  the 
same  security  class  as  its  result.  Since  queries  executed  on 
the  high  DBMS  often  require  access  to  low  data,  the  SD- 
DBMS  supports  the  transmission  of  data  from  the  low  to  the 
high  DBMS.  To  assure  that  no  data  flow  in  the  opposite 
direction,  all  such  transfers  are  constrained  to  go  through  the 
reference  monitor  (implemented  as  part  of  the  Data 
Manager).  Once  the  execution  of  the  subqueries  is  com¬ 
plete,  the  Data  Manager  retrieves  the  results  and  labels  them 
at  the  security  class  of  the  back-end  DBMS  on  which  they 
were  computed.  The  reference  moniior  then  mediates  the 
return  of  these  results  to  the  user. 

5.  Query  Decomposition  and  Execution 

The  previous  section  presented  an  architecture  for  the  SD- 
DBMS.  This  section  presents  u  notation  for  describing 
query  decomposition  and  processing  algorithms,  an  algo¬ 
rithm  for  the  recovery  (recomposition)  ot  multilevel  rela¬ 
tions,  and  algorithms  and  examples  tltat  describe  how  the 
relational  operators  are  implemented  within  the  architecture. 

5.1  Notation 

We  have  adopted  the  following  relational  algebra  notation  to 
express  the  queries  processed  by  the  SD-DBMS  [3|: 

(  A*  )  denotes  the  projection  of  the  relation  R,  on 
the  attribute',  a  (,  a  2,  ....  <i„ ;  o2,  ( R  )  denotes  selection  (res¬ 
triction),  where  P  is  the  selection  predicate;  /i  xS  denotes 
cross  product;  R  uS  denotes  union;  and  finally,  R  -S 
denotes  difference.  The  operator  <—  is  the  relation  assign¬ 
ment  operator.  These  relational  operators  can  be  nested  to 
reduce  the  need  for  temporary  relations  and  to  form  more 
compact  expressions  (e.g.,  ko1i  (R  xS  )). 

To  express  update  queries,  we  use  the  following  notation 
which  is  a  modified  version  of  that  used  in  the  query 
language  SQUARE  111}.  The  insertion  operator  has  the 
form:  lK  (  a  ,,  a2,  ■  ■■ ,  an\ v ,,  v2, ....  vn  )  denoting  the 
insertion  of  a  tuple  into  R,  where  a  a2,  •  •  1 ,  ct„  are  attri¬ 
butes  of  R,  and  v ,,  v2, ...,  v„  arc  values  for  those  attributes 
in  the  inserted  tuple.  The  deletion  operator  has  the  form; 
T R  {P  ),  where  P  is  a  predicate.  The  relation  R  is  searched 
for  tuples  that  satisfy  P,  and  all  matching  tuples  are  deleted. 
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The  modify  operator  has  the  form: 

~>R  (a  x  =  expr  1,  a2  =  cxprl . an  =  exprn ;  P  ),  where 

a  l.  a2<  '  <an  are  attributes  of  R,  ex pr  1,  expr  2, ....  exprn 

are  expressions  (possibly  involving  a a2,  ,  a,),  and  P 

is  a  predicate.  The  relation  R  is  searched  for  tuples  that 
satisfy  P,  the  specified  attributes  in  each  of  those  tuples  arc 
replaced  with  the  result  of  evaluating  the  corresponding 
expression. 

Since  a  basic  function  of  the  SD-DBMS  is  distributed  query 
processing,  two  operations  have  been  defined  to  describe  the 
distributed  execution  of  queries  and  dynamic  routing  of 
results.  The  operation  exec  (Q  ,C  )  is  used  to  execute 
query  Q  at  component  C.  The  operation 
leans  ( R ,  C 1 ,  C  2 )  is  used  to  transfer  (copy)  relation  R 
from  component  Cl  to  component  C2.  The  components  of 
the  architecture  are  indicated  by:  L  for  low  DBMS,  II  for 
high  DBMS,  D  for  Data  Manager,  and  U  for  User  Program. 

The  above  notation  is  summarized  in  table  5.1. 


Symbol 

Meaning 

JT 

Project 

O 

Select 

X 

Product 

u 

Union 

- 

Difference 

Assignment 

1 

Insen 

t 

Delete 

-» 

Modify 

nans 

Data  Transfer 

exec 

Subquery  Execution 

Table  5.1.  Notation  Summary 

5.2  Recovery  of  Multilevel  Relations 

The  execution  of  a  relational  operator  results  in  the  creation 
of  a  new  multilevel  relation.  This  multilevel  relation  can  be 
an  intermediate  or  final  result.  Intermediate  results  arc  rela¬ 
tions  that  are  to  be  used  as  operands  in  subsequent  relational 
operations.  Final  results  are  relations  to  be  returned  to  the 
subject.  The  last  step  in  processing  any  query  is  to  recover 
the  final  result  (multilevel  relation)  and  return  it  to  the  sub¬ 
ject.  A  multilevel  relation  is  recovered  by  copying  each  of 
its  fragments  to  the  Data  Manager,  labeling  the  tuples  in  the 
fragments  at  the  security  class  of  the  back-end  DBMS  from 
which  they  were  retrieved,  unioning  the  fragments  together, 
and  sending  the  result  to  the  requesting  User  Program.  This 
recovery  process  is  given  by  the  following  algorithm. 

Algorithm  5.1:  Given  a  retrieval  request  on  a  mul¬ 
tilevel  relation  R,  let  F„  be  the  set  of  fragments 
of  R  such  that  i  is  dominated  by  the  read  class  of 
the  subject.  For  each  fragment  Rt  e  FR ,  copy  Ri 
from  the  back-end  DBMS  c  to  the  Data  Manager, 
where  c  is  a  security  class  that  is  the  least  upper 
bound  of  t  and  the  level  of  the  retrieval  request. 


Then  execute  the  query  <—  Cj  Ri  on  the 

Hi  v  Fg 

Data  Manager,  where  T ^  is  a  temporary  relation, 
and  return  the  result  to  the  subject. 

Since  this  union  operation  returns  a  multilevel  result  it  must 
be  trusted.  This  is  indicated  by  the  star  in  the  symbol  u.  It 
should  be  noted  that  (depending  on  the  security  class  of  the 
query)  algorithm  5.1  may  require  fragments  to  be 
transferred  from  a  low  to  a  high  back-end  DBMS.  This  will 
occur  when  c  dominates  i.  As  mentioned  in  section  4,  such 
transfers  are  constrained  to  go  through  the  reference  mon.icr 
to  assure  that  no  data  flow  in  the  opposite  direction. 

The  recovery  of  a  multilevel  relation  is  illustrated  by  the  fol¬ 
lowing  example.  This  example,  and  the  other  examples  in 
this  section,  assume  the  security  class  of  the  submitted 
query  is  low.  In  appendix  A,  examples  are  given  with 
queries  at  different  security  classes.  Suppose  a  subject  with 
a  read  class  of  high  submits  a  query  that  results  in  a  request 

lor  multilevel  relation  R  to  be  returned.  The  system  would 


recover  R  as  follows. 

trails  (Rhw,L,D  )  (,1.1a) 

trans  (Rlligh,H,D)  (1.2a) 

(  A’m/  Rt»w  &  «/„>•. . D  )  (1.3a) 

traits  ( Rlnl,  D  ,U  )  (1.4a) 

If  the  same  query  were  submitted  by  a  subject  with  a  read 
class  of  low,  the  system  would  recover  R  as  follows. 

l.-ans  (.Rhw,L,D)  (1.1b) 

irons  ( Rhw,D,U)  (1.2b) 


5.3  Retrieval  Operators 

I  here  are  five  basic  relational  operators:  select,  project, 
product,  union,  and  difference  -  from  these,  other  useful 
relational  operators  can  be  derived  (e.g.,  join,  intersection, 
and  division).  This  section  discusses  the  five  basic  opera¬ 
tors  (since  all  other  operators  can  be  derived  from  them)  and 
a  generic  alpha  operator  used  to  illustrate  the  handling  of 
aggregate  operators  (e.g.,  MIN,  MAX,  and  AVG).  Query 
decomposition  and  processing  algorithms  for  these  opera¬ 
tors  that  assure  correct  labeling  of  derived  results  are 
presented  in  the  following  sections, 

5.3.1  Select.  A  select  on  a  multilevel  relation  is  processed 
by  decomposing  it  into  a  set  of  selects  on  single-level  frag¬ 
ments. 

Algorithm  5.2:  Given  a  select  query  aP  ( R  ), 
where  R  is  an  n-ary  multilevel  relation,  and  P  is 
the  select  predicate,  let  FR  be  the  set  of  fragments 
Ri  of  R  such  that  i  is  dominated  by  the  read  class 
of  the  subject.  For  each  fragment  R,  e  FR ,  if  Tc 
exists,  create  the  subquery  Tc  <-  Tc  u  aP  ( Aj  ); 
otherwise,  create  the  subquery  Tc  <-  ap  ( A’,  ); 
execute  the  subquery  on  the  back-end  DBMS  c, 
where  c  is  the  least  upper  bound  of  i  and  the  secu- 


182 


rity  glass  of  the  query. 

When  the  execution  of  these  subqueries  is  complete,  the 
answer  to  the  original  query  is  the  multilevel  relation  T.  T 
can  be  recovered  (using  algorithm  5.1)  and  returned  to  the 
user,  or  it  can  be  used  as  an  operand  in  further  relational  cal¬ 
culations. 

The  decomposition  and  processing  of  select  queries  is  illus¬ 
trated  by  the  following  example.  Suppose  a  subject  with  a 
read  class  of  high  submits  the  query  ou=10  ( ft  ).  The  sys¬ 
tem  would  decompose  this  query  into  the  following  set  of 
subqueries  and  operations: 

exec  (  Thw  <-  CTU=10  (  Rhw  ),  L  )  (2.1a) 

exec  (  Thij.h  <-  au  ,,1Cj  (  Rhiill  ),  //  )  (2.2a) 

If  the  same  query  were  submitted  by  a  subject  with  a  read 
class  of  low,  the  system  would  decompose  it  into  the  follow¬ 
ing  subquery: 

exec  (2 i0VJ  <—  ou=io  (  )•  7->  )  (2.1b) 

5.3.2.  Project.  A  project  on  a  multilevel  relation  is  pro¬ 
cessed  by  decomposing  it  into  a  set  of  projects  on  single- 
level  fragments. 

Algorithm  5.3:  Given  a  project  query  ka  ( R  ), 
where  R  is  an  n-ary  relation,  and  A  is  a  set  of  pro¬ 
ject  attributes,  let  FK  be  the  set  of  fragments  ft,  of 
R  such  that  i  is  dominated  by  the  read  class  of  the 
subject.  For  each  fragment  R,  e  FK,  if  Tc  exists, 
create  the  subquery  Tc  <-  7).  urt,t  ( ft,  );  other¬ 
wise,  create  the  subquery  Tc  f-  Jt,t  (  ft,  );  execute 
the  subquery  on  the  back-end  DBMS  c,  where  c  is 
the  least  upper  bound  of  i  and  the  security  class  of 
the  query, 

When  the  execution  of  these  subqueries  is  complete,  the 
answer  to  the  original  query  is  the  multilevel  relation  T. 

The  decomposition  and  processing  of  project  queries  is 
illustrated  by  the  following  example.  Suppose  a  subject 
with  a  read  class  of  high  submits  the  query  rc,  „  ( R  ).  The 
system  would  decompose  tins  query  into  the  following  set 
of  subqueries  and  operations: 

exec  (  7 !ow  <—  tt£iJ  (  A'(cmv  ),  L  )  (3.1a) 

twee  (  7 /ugh  *  ^x,a  (^high  )»  77  )  (3.2a) 

If  the  same  query  were  submitted  by  a  subject  with  a  read 
class  of  low,  the  system  would  decompose  it  into  the  follow¬ 
ing  subquery: 

exec  (  Thw  t-  (  R,vw  ),  L  )  (3.1b) 

5.3.3.  Product.  The  product  of  multilevel  relations  is  pro¬ 
cessed  by  decomposing  it  into  a  set  of  products  of  single¬ 
level  fragments. 

Algorithm  5.4:  Given  the  product  query  ft  xS, 
where  R  and  S  arc  n-ary  relations,  let  FK  be  the  set 
of  fragments  ft;  of  R  such  that  i  is  dominated  by 


the  read  class  of  the  subject,  and  Fs  be  the  set  of 
fragments  5,  of  S  such  that  i  is  dominated  by  the 
read  class  of  the  subject.  For  each  pair  of  frag¬ 
ments,  ft;  e  Fr  ,  Sj  e  F: v  ,  if  Tc  exists,  create  the 
subquery  7’c  <-  Tc  u ft;  xS y,  otherwise,  create 
the  subquery  Tc  <—  ft;  x  Sj ;  execute  the  subquery 
on  on  the  back-end  DBMS  c,  where  c  is  the  least 
upper  bound  of  i,  j,  and  the  security  class  of  the 
query. 

When  the  execution  of  these  subqueries  is  complete,  the 
answer  to  the  original  query  is  the  multilevel  relation  T. 

The  decomposition  and  processing  of  product  queries  is 
illustrated  by  the  following  example.  Suppose  a  subject 
with  a  read  class  of  high  submits  the  query  ft  xS .  The  sys¬ 
tem  would  decompose  this  query  into  the  following  set  of 
subqueries  and  operations: 


exec 

(  T’iow 

<—  Rjow  > 

"■  3/olt, ,  L,  ) 

(4.1a) 

trans 

( Tf.w 

,L,H) 

(4.2a) 

trans 

(  3; o,,, 

,L,H  ) 

(4.3a) 

exec 

(Tu# 

*  Rluw 

x  Shigh  >  77  ) 

(4.4a) 

exec 

( 7'hish 

Thigh 

u  (  7 l/ugl,  x  Sfow 

),  ll  )  (4.5a) 

exec 

(  Thigh 

Thish 

W  (  ^lugh  x 

),  77  )(4.6a) 

If  the  same  query  were  submitted  by  a  subject  with  a  read 
class  of  low,  the  system  would  decompose  it  into  the  follow¬ 
ing  subquery: 

exec  ( Thw  <-  RUnv  x  Shw ,  L  )  (4. 1  b) 

5.3.4.  Union.  The  union  of  multilevel  relations  is  processed 
by  decomposing  it  into  a  set  of  unions  of  single-level  frag¬ 
ments  at  a  single  security  level. 

Algorithm  5.5:  Given  a  union  query  ft  uft, 
where  R  and  S  are  n-ary  multilevel  relations,  for 
each  security  class  i  e  rangc(R)  u  rangc(S)  that  is 
dominated  by  the  read  class  of  the  subject,  if  Tc 
exists,  create  the  subquery  Tc  Tc  u  (  ft,  u  ft,-  ); 
otherwise,  create  the  subquery  Tc  <—  ft,  u  Sj  ;  exe¬ 
cute  th.  subquery  on  the  back-end  DBMS  c,  where 
c  is  the  least  upper  bound  of  i  and  the  security 
class  of  the  query, 

When  the  execution  of  these  subqueries  is  complete,  the 
answer  to  the  original  query  is  the  multilevel  relation  T. 

The  decomposition  and  processing  of  union  queries  is  illus¬ 
trated  by  the  following  example.  Suppose  a  subject  with  a 
read  class  of  high  submits  the  query  ft  uS,  The  system 
would  decompose  this  query  into  the  following  set  of 
subqueries  and  operations: 

exec  (  Tlow  «-  Rhw  vjS1ow,L  )  (5.1a) 

exec  (  TUgh  <-  R^h  w  Shigh ,  II  )  (5.2a) 

If  the  same  query  were  submitted  by  a  subject  with  a  read 
class  of  low,  the  system  would  decompose  it  into  the  follow¬ 
ing  subqtiery: 


C’.xcc  (  Tkm  <-  Aw  xjSIuw,  L  )  (5.1b) 

5.3.5.  Difference.  The  difference  of  two  multilevel  rela¬ 
tions  is  processed  by  decomposing  it  into  a  set  of  differ¬ 
ences. 

Algorithm  5.6:  Given  a  difference  query  A’  -  S. 
where  R  and  S  are  n-ary  multilevel  relations,  let 
/’/}  be  the  set  of  fragments  A,  of  R  such  that  i  is 
dominated  by  the  read  class  of  the  subject,  and  Fs 
be  the  set  of  fragments  5;  of  S  such  that  i  is  dom¬ 
inated  by  the  read  class  of  the  subject.  For  each 
fragment  A,  e  FH .  if  Tc  exists,  create  the 
subquery  Tc  <-  Tc  u  ( A/  -  u  Si );  otherwise, 

s,zrs 

create  the  subquery  '/'L.  <— ■  A(  -  u  S. ;  execute 

S,  6  FS 

the  subquery  on  the  back-end  DBMS  c,  where  c  is 
the  least  upper  bound  of  i,  the  security  classes  of 
the  fragments  in  Fs,  and  the  security  class  of  the 
query. 

When  the  execution  of  these  subqueries  is  complete,  the 
answer  to  the  original  query  is  the  multilevel  relation  T. 

The  decomposition  and  processing  of  difference  queries  is 
illustrated  by  the  following  example.  Suppose  a  subject 
with  a  read  class  of  high  submits  the  query  A  -  S .  The  sys¬ 
tem  would  decompose  this  query  into  the  following  set  of 
subquerics  and  operations: 

irons  (  Rtliw,  L,  11  )  (6.1a) 

irons  (Shw,l.,fl  )  (6.2a) 

cacc  {  i  itt^h  *  ^ low  )<  f  f  )  (6.3a) 

vxcc  (  Th,Kit  *-  7 u  (  Khilth  -  (6.4a) 

(  ■''low  U  ))•(-) 

If  the  same  query  were  submitted  by  a  subject  with  a  low 
read  class,  the  system  would  decompose  it  into  the  follow¬ 
ing  set  of  subqueries: 

e.u'c  (  T,ua  <  /'/„*.  •-  A/,,,, ,  /.  )  (6. 1  b) 

5.3.6.  Aggregate.  An  aggregate  computed  on  a  multilevel 
relation  is  processed  by  computing  the  aggregate  over  the 
single-level  fragments  of  the  relation  and  labeling  the  result 
at  the  least  upper  bound  of  the  fragment  security  classes  and 
the  security  class  of  the  query, 

Algorithm  5.7:  Given  an  aggregate  query  u  (  A  j, 
where  u  is  an  aggregate  operator  and  R  is  an  n-ary 
multilevel  relation,  let  Ft/  be  the  set  of  fragments 
A,  of  R  such  that  i  is  dominated  by  the  read  class 
of  the  subject.  Execute  the  subquery 
7‘  <-  u  (  u  A,  )  on  the  back-end  DBMS  e, 

It.  f  Fs 

where  e  is  the  least  upper  bound  of  the  security 
classes  of  the  fragments  in  Fl{  and  the  security 
class  of  the  query. 


When  the  execution  of  these  subqueries  is  complete,  the 
answer  to  the  original  query  is  the  multilevel  relation  T.  T 
consists  of  a  single  fragment  at  the  security  class  of  the  least 
upper  bound  of  all  the  data  used  in  its  derivation. 

The  decomposition  and  processing  of  aggregate  queries  is 
illustrated  by  the  following  example.  Suppose  a  subject 
with  a  read  class  of  high  submits  the  query  a(A  ).  The 
system  would  decompose  this  query  into  the  following  set 
of  subqucries  and  operations: 

turns  (  A/(W,  L,  //  )  (7.1a) 

exec  (  Tlligh  <—  a  (  Rtow  kj  Riligh  ),  H  )  (7.2a) 

If  the  same  query  were  submitted  by  a  subject  with  a  low 
read  class,  the  system  would  decompose  it  into  the  follow¬ 
ing  subquery: 

exec  (  Tlow  <-  a  ( Rhw  ),  L  )  (7.1b) 

5.4.  Update  Operators 

The  three  basic  update  operators  are  insert,  delete,  and 
modify.  This  section  covers  algorithms  for  these  operators 
that  assure  that  updates  get  reflected  in  the  appropriate  frag¬ 
ments.  The  fragments  to  be  updated  depends  of  the  level  of 
the  update,  which  is  indicated  by  the  security  class  of  the 
query.  Examples  are  not  given  for  these  algorithms  since 
their  operation  is  straightforward. 

5.4.1.  Insert.  An  insertion  into  a  multilevel  relation  is  pro¬ 
cessed  by  inserting  the  data  in  the  appropriate  fragment  of 
that  relation.  The  fragment  in  which  to  insert  the  data  is 
determined  by  the  security  class  of  the  query.  Note  that  the 
security  class  of  the  query  always  dominates  the  write  class 
of  the  subject. 

Algorithm  5.8:  Given  an  insert  query 
•1-A  (  a  |,  a 2,  ■  •  ■ ,  «„ ;  v  |,  v2, v„  )  ,  where  R  is 
a  multilevel  relation,  execute  the  subquery 
4At.  (i/i.iij,  •  •  ■ ,  an ;  v ,,  v2 . vn  )  0,1  back¬ 

end  DBMS  c,  where  c  is  the  security  class  of  the 
query. 

5.4.2.  Delete.  A  deletion  front  a  multilevel  relation  is  pro¬ 
cessed  by  deleting  tuples  in  the  the  appropriate  fragments. 
These  are  the  fragments  having  a  security  class  that  dom¬ 
inates  the  security  class  of  the  query  and  is  dominated  by 
read  class  of  the  subject. 

Algorithm  5.9:  Given  a  delete  query  Ta  (A  ), 
where  R  is  a  multilevel  relation,  and  P  is  a  predi¬ 
cate,  let  Fj.  be  the  set  of  fragments  A,  of  A  such 
that  i  is  dominated  by  the  read  class  of  the  subject, 
and  i  dominates  the  security  class  of  the  query. 

For  each  fragment  A;  6  FK,  execute  the  query 
Ta,  (  A  )  on  back-end  DBMS  t. 

5.4.3.  Modify.  A  modification  to  a  multilevel  relation  is 
processed  hv  modifying  the  tuples  in  the  appropriate  frag¬ 
ments.  '"'Ik  are  the  fragments  having  a  security  class  that 
dominates  the  security  class  of  the  query  and  is  dominated 
by  read  class  of  the  subject. 
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Algorithm  5.10:  Given  a  modify  query 

a  \=cxpr  1,  a  2=cxj>r  2,  >  un=cxprn  ;  ^  )»  wllCIC 

a  ,,  a  2,  ■ -  • .  an  are  attributes  of  R, 
exprl,  expi'2, exprn  are  expressions  (possibly 
involving  ctj.rt;,  ■••,«,,),  and  P  is  a  predicate, 
let  Fr  be  the  set  of  fragments  of  of  R  such  that 
i  is  dominated  by  the  read  class  of  the  subject,  and 
i  dominates  the  security  class  of  the  query.  For 
each  fragment  /?,  e  F!t,  execute  die  query 

(  0  1  -cXpr  1,  a  2,  -cxpr  2,  •>  'ln --<xprn  ;  F  )  0,1 

back-end  DBMS  i. 

6.  Data  Replication 

The  query  processing  performance  of  the  SD-DBMS  archi¬ 
tecture  is  likely  to  suffer  because  of  the  need  to  transfer  low 
fragments  to  the  high  back-end  DBMS  in  order  to  process 
queries.  In  order  to  lesson  or  eliminate  this  performance 
penalty,  the  SD-DBMS  permits  sonic  or  all  of  the  low  frag¬ 
ments  to  be  replicated  on  the  high  back-end  DBMS.  Low 
fragments  replicated  on  the  high  back-end  DBMS  can  be 
used  in  high  queries  instead  of  fetching  a  new  copy  from  the 
low  back-end  DBMS  each  time  it  is  needed.  Partial  replica¬ 
tion  (i.e.,  replicating  the  low  fragments  of  sonic,  but  not  all, 
relations)  is  considered  to  be  a  viable  alternative  because  it 
is  expected  that  certain  low  fragments  will  be  needed  on  the 
high  back-end  DBMS  more  frequently  than  others,  The 
decision  of  which  fragments  to  replicate  could  be  based  on 
statistics  collected  by  the  SD-DBMS.  If  a  particular  low 
fragment  is  ftequently  needed  on  the  high  back-end  DBMS, 
then  the  overhead  of  replicating  it  is  justified.  However,  if  a 
particular  low  fragment  is  infrequently  (or  never)  needed  on 
the  high  back-end  DBMS,  then  replication  is  not  just  Tied, 
and  the  fragment  should  be  transferred  to  the  high  back-end 
DBMS  on  an  as-needed  basis.  Thus,  the  partial  replication 
approach  provides  a  method  of  tuning  the  physical  database 
structure. 

The  main  disadvantage  of  replicating  data  (besides  llic  obvi¬ 
ous  storage  overhead)  is  the  problem  of  synchronizing 
updates  between  replicated  copies  of  low  data.  The  solution 
to  this  problem  in  the  SD-DBMS  is  to  make  one  copy  (the 
low  copy)  the  primary  copy,  and  all  other  copies  secondary 
copies.  Only  the  primary  copy  is  permitted  to  be  updated  by 
users.  User  updates  to  the  primary  copy  are  then  propagated 
to  all  secondary  copies  by  the  system.  '1  ltis  technique 
avoids  the  problem  of  simultaneous  updates  to  replicated 
copies  of  the  data  resulting  in  an  inconsistent  database. 
Since  all  updated  must  be  applied  to  the  primary  copy  lirst, 
the  concurrency  control  mechanisms  on  the  low  back-end 
DBMS  can  prevent  conflicting  user  updates.  Using  this 
approach,  if  a  serious  loss  of  synchronization  should  occur, 
it  could  always  be  corrected  by  removing  the  replicated 
fragment  and  recopying  the  (low)  primary  copy. 

7,  Covert  Channels 

A  serious  problem  with  back-end  DBMS  architectures  is 
that  a  Trojan  horse  in  a  high  user  program  could  use  queries 


sent  to  the  low  back-end  DBMS  as  a  high  bandwidth  covert 
storage  channel  [1],  This  attack  could  take  a  number  of 
forms.  The  most  highly  recognized,  and  potentially  the 
most  devastating,  is  that  a  Trojan  horse  in  a  high  user  pro¬ 
gram  could  encode  arbitrary  high  data  in  the  qualification 
portion  of  the  selection  query  to  be  leaked  to  the  low  back¬ 
end  DBMS.  A  cooperating  Trojan  horse  in  the  low  back¬ 
end  DB1  IS  could  then  extract  the  high  data  from  the  query 
and  release  it  to  a  low  user.  The  following  example,  bor¬ 
rowed  from  Hinke  [12],  illustrates  this  problem.  Suppose 
the  following  query  is  submitted  from  a  high  user  program: 

retrieve  NAME  where  ADDRESS  =  "504  Pershing  Square". 

If  this  query  is  directed  to  the  low  back-end  DBMS,  the 
Data  Manager  cannot  determine  whether  it  is  a  legitimate 
query  asking  for  employees  at  a  particular  address,  or 
whether  it  has  been  sent  by  a  Trojan  horse  in  the  user  pro¬ 
gram,  with  the  intent  of  leaking  the  Top  Secret  fact  that  504 
pershing  missiles  are  to  be  deployed.  This  threat  is  not  lim¬ 
ited  to  selection  queries,  since  other  types  of  queries  (e.g., 
projections,  joins,  etc.)  can  potentially  be  used  as  a  covert 
leakage  channel  when  sent  down  in  security  class  (e.g.,  by 
modulating  the  attribute  and  relation  names  in  the  query). 

The  architecture  presented  in  this  paper  does  not  suffer  from 
this  vulnerability.  This  is  because  in  SD-DBMS  architec¬ 
ture  assigns  each  query  a  security  class  and  strictly  enforces 
the  constraint  that  a  query  is  never  executed  on  a  back-end 
DBMS  strictly  dominated  by  its  security  class.  In  the  exam¬ 
ple  above,  since  the  query  was  entered  from  an  untrusted 
high  user  program,  the  level  of  the  query  would  be  high,  and 
therefore  the  query  would  be  executed  on  the  high  haek-end 
DBMS  and  the  results  would  be  returned  as  high.  However, 
if  the  high  user  program  were  trusted,  it  could  reliably  com¬ 
municate  to  the  Data  Manager  the  level  of  the  query  as  low, 
and  the  query  could  be  sent  to  the  low  bnek-end  DBMS  to 
return  low  results. 

It  should  be  noted  that  a  covert  channel  may  still  exist.  The 
execution  ot  queries  that  access  low  data  on  the  high  back¬ 
end  DBMS  requires  that  data  be  copied  from  the  low  to  die 
high  back-end  DBMS.  These  copy  requests  can  be  used  as  a 
covert  channel,  albeit  one  of  substantially  lower  bandwidth. 
This  channel  can  be  eliminated  by  fully  replicating  the  low 
data  on  the  high  back-end  DBMS  thereby  eliminating  the 
need  to  copy  data.  This  approach  eliminates  the  coven 
channel  at  the  cost  of  increasing  the  overhead  of  propagating 
updates.  Another  approach  would  be  to  use  partial  or  no 
replication,  and  simply  audit  the  channel  and  prevent  it  from 
exceeding  some  predetermined  threshold  (e.g.,  by  metering 
the  flow  of  copy  requests  within  the  Data  Manager). 

9.  Summary  and  Conclusions 

This  paper  presented  a  distributed  architecture  for  multilevel 
database  security.  The  architecture  was  defined  in  such  a 
way  that  it  provides  trusted  tuple  level  labeling  without 
requiring  the  relational  operators  to  be  trusted.  This  permits 
a  near-term  implementation  of  this  architecture  that  uses 
existing  DBMS  technology  to  implement  the  majority  of 
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database  operations.  Another  important  aspect  of  this  archi¬ 
tecture  is  that  it  i  cognizes  the  role  the  query  plays  in  the 
security  class  of  derived  results.  Reflecting  the  security 
class  of  the  query  in  the  security  class  of  results  allows  this 
architecture  to  provide  tuple  level  labels  that  can  be  safely 
used  in  mandatory  access  control  decisions. 
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Appendix  A 

Query  Processing  Examples 


This  appendix  presents  three  query  processing  examples  that 
illustrate  how  a  simple  query  is  decomposed  and  processed 
in  the  architecture.  The  examples  were  selected  in  such  a 
way  that  they  also  illustrate  the  effect  of  the  security  class  of 
the  query,  and  data  replication,  on  query  decomposition  and 
processing.  All  three  of  the  examples  are  based  on  the 
query  shown  in  figure  A.l.  The  multilevel  database  used  in 
these  examples  is  the  database  shown  in  table  4.1. 

na,b,c  (oa=l0(R  xS  )) 

Figure  A.l.  Example  Query. 

A.l  Example  1:  High  User/Low  Query 

This  example  illustrates  how  the  query,  shown  in  figure  A.l, 
would  be  processed  if  it  were  en.  tred  by  a  high  subject  and 
was  labeled  low.  Note  that,  for  a  query  to  be  entered  by  a 
high  subject  and  be  labeled  low,  the  subject  would  have  to 
be  trusted  (multilevel). 

exec  (  T[ow  <  ^a,b  ,c  (  *7  a =10  (  ^  ^low  ))>^)  (LI) 

trans  (  Riow  ,L,H)  (L2) 

trans  (Stow,l.,H  )  (1.3) 

exec  (  Thioh  na.b,c  (  °a-10  (  Rfow  x  ^  high  ))>H)  0  -4) 

exec  ( TUgh  *-  Thigh  u  1 .5) 

(  ^ a,b,c  (^a  =  10  (  ^high  x  ^low  )  )  )>  H) 


exec  (  f'high  *  ^high  ^ 

(L6) 

(  ^atb,c  V^a  =  10  (  ^  high  *  ^ high  )  ) 

),//) 

trans  ( Tiow,LfD  ) 

(L7) 

trans  (  Thigh>  U ,  D  ) 

(1.8) 

exec  (  Tm[  <r-  Tjow  vj  ’Thigh*  T)  ) 

(1.9) 

trans  (  Tml,D ,  U  ) 

(1.10' 
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In  step  1.1  the  low  part  of  the  result  is  computed.  This 
result  is  stored  in  the  fragment  Ttew.  In  steps  1.2  and  1.3, 
the  low  fragments  of  R  and  S  are  transferred  to  the  high 
back-end  DBMS  so  that  they  can  be  used  to  compute  the 
high  part  of  the  result.  Note  that,  if  the  data  were  fully  repli¬ 
cated,  steps  1.2  and  1.3  could  be  eliminated.  In  steps  1.4- 
1.6,  the  high  part  of  the  result  is  computed.  This  result  is 
stored  in  Thish,  At  this  point,  the  execution  of  the  query  is 
complete  and  the  result  is  the  multilevel  relation  T.  This 
multilevel  result  was  possible  because  the  read  class  of  the 
subject  (high)  strictly  dominated  the  security  class  of  the 
query  (low).  In  steps  1.7-1 .10,  T  is  recovered  and  returned 
to  the  subject. 

A.2  Example  2:  High  User/Kigh  Query 

This  example  illustrates  how  the  the  query,  shown  in  figure 
A.l,  would  be  processed  if  it  were  entered  by  a  high  subject 
and  was  labeled  high.  In  this  case,  either  the  subject  could 
have  been  untrusted  (single-level)  and  the  query  was  taken 
to  be  its  read  class,  or  the  subject  ^ould  have  been  trusted 
(multilevel)  and  could  have  indicated  to  the  Data  Manager 


that  the  security  class  of  the  query  was  high. 
trans  ( Riow,  L,H  )  (2.1) 

trails  (Slow,L,H  )  (2.2) 

exec  (  Thish  <-  na iC  ( Oa _ l0  ( Rtow  *Slo„)),H  )  (2.3) 

exec  (  TUgh  <  -  Thigk  u  (2.4) 

(  ^a.h,c  (^a  =  10  (  ^low  *  ^ high  )  )  )>  TT) 

exec  (  Thigh  Thigh  (2.5) 

(  na,h,c  (°a=10  (  ^hi/h  x  ^low  )  )  )•  W) 

(  Thigh  <-■  Thigh  ^  (2.6) 

(  ^u.A.c  (*^a  =  10  (  ^liigh  *  ‘'high  )  )  )>  Ti ) 

trails  (TUgh,H ,D  )  (2.7) 

trans  (Thifg.D.U  )  (2.8) 


In  this  example,  the  entire  result  will  be  high  because  the 
security  class  of  the  query  (high)  is  equal  to  the  read  class  of 
the  subject  (high).  In  steps  2.1  and  2.2,  the  low  fragments  of 
R  and  S  are  transferred  to  the  high  back-end  DBMS  so  that 
they  can  be  used  to  compute  the  high  part  of  the  result. 
Note  that,  if  the  data  were  fully  replicated,  steps  2.1  and  2.2 
could  be  eliminated.  In  steps  2. 3-2.6,  the  high  part  of  the 
result  is  computed.  At  this  point,  the  execution  of  the  query 
is  complete  and  the  result  is  the  multilevel  relation  T  which 
consists  of  the  single  fragment  Thish .  In  steps  2.7  and  2.8,  T 
is  recovered  and  returned  to  the  subject. 


A.3  Example  3:  Low  User/Low  Query 

This  example  illustrates  how  the  query,  shown  in  figure  A.l, 
would  be  processed  if  it  were  entered  by  a  'ow  subject.  In 
this  case,  the  query  obviously  must  be  labele. .  low. 

exec  ( Thw  <-  7ta>6>c  ( afl=10  ( Rlow  x  Slow  )),L)  (3.1) 

trans  (Tlow>L,D  )  (3.2) 

trans  (Tlew,D,U  )  (3.3) 

In  this  example,  the  result  will  be  low  since  the  low  user  can 
only  see  low  data.  In  step  3.1,  the  low  (and  only)  part  of  the 
result  is  computed  and  stored  in  Tlow  At  this  point,  the  exe¬ 
cution  of  the  query  is  complete  and  the  result  is  the  mul¬ 
tilevel  relation  T  which  consists  of  the  single  fragment  T/ow . 
In  steps  3.2  and  3.3,  T  is  recovered  and  returned  to  the  sub¬ 
ject. 
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A  Summary  of  the 
RADC  Database  Security  Workshop 


Teresa  F.  Lunt 

SRI  International,  Computer  Science  Laboratory 
333  Ravenswood  Ave.,  Menlo  Park,  CA  9*1025 


1  Introduction 

On  May  24-26,  1988,  Teresa  Lunt  of  SRI  led  a  database 
security  workshop  at  Vallombrosa  Conference  and  Retreat 
Center  in  Menlo  Park,  California.  About  25  researchers 
working  on  multilevel  security  for  database  systems  at¬ 
tended.  The  workshop  was  the  first  extended  techni¬ 
cal  interchange  among  those  participating  in  the  following 
projects,  most  of  which  were  inspired  by  the  1982  Air  Force 
Summer  Study  [ij:  SRI’s  ind  Gemini  Computer’s  ScaView 
A1  multilevel  relational  database  system  [2|;  TRW’s  A1  Se¬ 
cure  Prototype  DBMS  |3|;  the  Unisys  133  secure  database 
system  project;  Honeywell’s  LOCK  Data  Views  (LDV) 
project  [4];  MlTRE’s  Kernelized  Trusted  DBMS  project; 
the  Naval  Research  Laboratory’s  Secure  Military  Message 
System  |5);  AOG  Systems’  secure  entity-relationship  (E-R) 
project  (Oj ;  MlTRE’s  Integrity  Lock  project  [7|;  and  the 
Hinke-Schaofcr  secure  database  project  [8]. 

The  workshop  began  with  short  presentations  on  the 
research  projects  currently  under  way,  and  most  of  the  rest 
of  the  sessions  wore  devoted  to  discussions  of  the  advantages 
and  disadvantages  of  the  various  approaches  to  multilevel 
database  security  that  have  been  tried,  difficult  issues  that 
have  resisted  solution,  and  new  approaches  to  multilevel 
database  security.  Below  we  review  some  of  the  discussions 
on  these  topics. 

2  Labels 

The  group  debated  the  issue  of  trusted  versus  advisory  la¬ 
bels  for  data.  Some  projects  (e.g.,  Sea  View)  return  an  ad¬ 
visory  label  with  the  data  because,  according  to  the  star 
property,  the  data  returned  to  a  user  arc  classified  at  the 
subject  class;  moreover,  any  internal  labels  on  the  individ¬ 
ual  data  elements  have  been  handled  by  untrusted  (relative 
to  mandatory  security)  code,  so  they  cannot  be  guaran¬ 
teed  to  be  correct  for  the  stored  data.  Some  projects  (e.g., 
TRW's  A1  prototype)  do  not  return  any  labels  with  the 
data,  on  the  theory  that  advisory  labels  could  be  harmful 
if  they  cannot  be  guaranteed  to  be  correct.  Other  projects 
(e.g.,  the  Unisys  project)  return  a  trusted  label,  with  the 
mandatory  TCB  extending  out  to  the  user’s  screen. 

The  participants  expressed  diverse  opinions  about  these 
approaches.  Some  said  the  lack  of  labels  could  be  confus¬ 
ing  if  data  are  poly  instantiated.  Others  believed  trusted 
labels  are  essentia!  for  trusted  multilevel  applications,  and 
yet  others  doubted  that  users  would  make  any  use  of  trusted 
labels,  whether  returned  directly  by  the  database  system  or 
through  a  trusted  application,  because  trusted  applications 
are  too  complex  and  difficult  to  build. 


3  Aggregation 

The  aggregation  problem  arises  when  a  set  of  items  of  in¬ 
formation,  all  of  which  are  classified  at  some  level,  become 
classified  at  a  higher  level  when  combined.  The  group  de¬ 
bated  the  approaches  taken  in  LDV  and  SeaView.  The  LDV 
approach  is  to  store  all  the  data  forming  the  aggregate  at 
the  low  level,  detect  when  the  aggregate  has  been  retrieved, 
and  mark  up  (or  withhold)  the  result.  In  the  SeaView  ap¬ 
proach,  all  (or  some)  of  the  items  forming  the  aggregate 
are  stored  at  the  aggregate-high  level,  and  subsets  can  be 
retrieved  at  the  lower  level  only  through  sanitization.  Some 
participants  agreed  that  storing  all  the  aggregate  data  at 
a  level  lower  than  the  aggregate  level  may  not  be  safe.  In 
addition,  one  attendee  noted  that  withholding  data  from 
one  file  when  a  related  file  has  been  accessed  (as  in  LDV) 
can  create  an  unnecessary  denial-of-service  problem. 

Another  issue  between  LDV  and  SeaView  is  that  many 
of  the  so-called  aggregation  problems  that  LDV  is  designed 
to  detect  can  be  readily  solved  through  appropriate  data 
design.  When  the  intent  is  to  hide  sensitive  relationships 
between  data  items  that  individually  are  not  sensitive,  the 
data  can  be  stored  at  a  low  level  and  the  sensitive  relation¬ 
ships  can  be  stored  at  a  high  level.  The  data  are  thus  avail¬ 
able  to  low  subjects  while  the  sensitive  relationships  are 
automatically  protected  by  the  underlying  mandatory  se¬ 
curity  mechanisms,  without  relying  on  complicated  trusted 
software  to  detect  violations.  With  adequate  database  de¬ 
sign  tools  (such  as  the  inference  control  tool  proposed  by 
Matt  Morgcnstern  of  SRI  [9]),  a  proposed  database  design 
can  be  analyzed  for  such  problems  and  restructured  to  elim¬ 
inate  or  minimize  the  problems. 

4  Discretionary  Security 

Dorothy  Denning  raised  the  question  of  whether  a  database 
could  be  partitioned  by  discretionary  permissions  as  well 
as  by  classification.  If  so,  stored  data  (i.e. ,  storage  objects) 
could  be  appropriately  marked  with  their  access  control 
lists,  and  the  discretionary  authorizations  for  relations  and 
views  would  be  derived  from  those  of  the  underlying  stor¬ 
age  objects.  This  offers  the  possibility  of  achieving  greater 
assurance  for  discretionary  security  than  if  discretionary  se¬ 
curity  attributes  are  associated  with  views  because  of  the 
complex  mechanism  involved  in  view  evaluation.  Views  do 
not  partition  u  database  because  they  may  overlap,  and 
views  defined  using  conditional  clauses  may  map  to  chang¬ 
ing  subsets  of  the  database  as  the  data  are  modified.  Helena 
Winkler  of  Sybase  explained  that  Sybase’s  secure  database 
product  (currently  under  development)  associates  access 
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control  attributes  not  with  views  but  rather  with  the  base 
relations,  which  are  mapped  directly  to  storage  objects. 
Sybase  believes  that  although  access  to  the  program  im¬ 
plementing  the  view  could  be  controlled,  because  the  view 
compiler  is  untrusted  no  assurance  exists  that  the  compiled 
view  maps  to  the  same  set  of  data  that  is  described  in  the 
view  definition. 

Some  participants  believed  that  partition'- ng  the 
database  with  discretionary  security  attributes  would  mean 
that  a  repartitioning  would  be  required  when  authoriza¬ 
tions  were  granted  and  revoked.  Others  pointed  out,  how¬ 
ever,  that  no  repartitioning  or  modifying  access  control  lists 
is  necessary  if  users  are  moved  in  and  out  of  groups, 

bunt  raised  some  other  discretionary  security  issues  for 
A1  and  B3  database  systems  that  stem  from  the  require¬ 
ments  in  the  Trusted  Computer  System  Evaluation  Crite¬ 
ria  (10]  for  support  for  group  authorizations  and  specific  de¬ 
nial  of  authorizations.  Because  the  set  of  users  and  groups 
authorized  for  an  object  is  independent  of  the  set  denied 
authorization,  apparent  conflicts  between  the  two  sets  may 
exist,  raising  the  questions:  What  does  denial  of  autho¬ 
rization  mean,  and  how  do  we  reconcile  the  authorizations 
granted  to  users  individually  and  as  members  of  groups? 

Denial  of  authorization  can  be  used  merely  as  a  conve¬ 
nience  in  forming  access  control  lists.  For  example,  granting 
group  G  authorization  and  denying  user  U  in  G  authoriza¬ 
tion  can  make  the  object  in  question  available  to  everyone 
in  G  except  V .  With  this  interpretation,  if  user  U  is  denied 
authorization  by  one  user  but  is  later  granted  authoriza¬ 
tion  by  another,  then  U  becomes  authorized.  A  stronger 
interpretation  of  denial  is  that  denials  take  precedence  over 
authorizations:  One  user’s  denial  operation  could  not  be 
negated  by  another’s  later  grant  operation. 

In  some  applications,  a  user  may  belong  to  more  than 
one  group.  In  assigning  privileges  to  subjects  acting  on 
behalf  of  a  user,  one  must  decide  whether  the  subject  should 
operate  with  the  union  of  the  user’s  individual  privileges 
and  the  privileges  of  all  the  groups  the  user  belongs  to, 
whether  the  subject  should  operate  witli  the  privileges  of 
only  one  group  at  a  time,  or  whether  some  other  policy 
should  be  adopted.  These  questions  should  be  examined 
further  (11]. 

5  The  Homework  Problem 

Experience  with  applying  MITRE’s  Integrity  Lock  secure 
database  system  to  a  particular  secure  database  application 
motivated  Rae  Burns  of  Kanne  Associates  to  devise  a  home¬ 
work  problem,  which  she  posed  to  the  group.  The  group 
broke  up  into  three  teams  to  work  on  it.  They  worked  late 
into  the  evening  and  on  the  following  morning  animatedly 
discussed  the  homework  problem,  as  the  team  leaders  pre¬ 
sented  their  approaches  to  the  problem.  Many  of  those  at¬ 
tending  considered  the  homework  problem  the  single  most 
valuable  part  of  the  workshop,  The  homework  problem  is 
appended  to  this  paper. 

6  Classification  Semantics 

Gary  Smith  of  George  Mason  University  led  a  discussion 
on  the  semantics  of  data  classification.  Smith  believes  that 
information  should  be  classified  at  a  level  that  reflects  its 
contents,  not  its  derivation.  He  introduced  three  dimen¬ 


sions  to  security  semantics:  content  (e.g.,  flights  to  Iran  can 
be  classified  because  of  the  value  ‘Iran’),  description  (e.g., 
the  fact  that  flights  to  Iran  are  classified  may  itself  be  clas¬ 
sified),  and  existence  (e.g.,  the  existence  of  a  flight  to  Iran 
may  be  classified,  or  the  existence  of  classified  flights  may 
be  classified).  For  data,  he  enumerated  the  following  secu¬ 
rity  semantics:  data  values  classified  by  themselves  (e.g., 
self-describing  data  or  implicit  associations),  data  values 
classified  in  association  with  an  attribute  name,  multiple 
attribute  associations,  functional  dependencies,  temporal 
associations,  and  quantity  aggregations. 

The  group  also  discussed  automatic  classification  of 
text.  Smith  graded  the  following  tasks  from  easy  to  hard: 
keyword  search,  classifying  simple  references,  classifying 
disambiguated  text,  classifying  text  in  limited  domains,  and 
classifying  free-form  text.  Some  argued  that  systems  such 
as  Classi,  an  automated  text  classification  system  proposed 
by  Lunt  and  Berson  [12],  should  be  pursued  because  hu¬ 
mans  are  not  as  consistent  as  machines  that  classify  text 
and  because  systems  like  Classi  could  address  the  under¬ 
supply  of  qualified  human  experts.  Others  cautioned  that 
such  consistency  may  lead  to  a  false  sense  of  security  if  the 
inconsistency  of  the  humans  can  be  attributed  to  rules  that 
were  not  captured  by  the  expert  system.  They  warned  of 
the  risk  that  the  expert  system  may  be  used  outside  its 
domain  of  expertise,  in  which  case  the  system  should  rec¬ 
ognize  this  and  answer,  “I  don't  know,”  Untrusted  subjects 
in  the  expert  system  classifier  could  tamper  with  the  classi¬ 
fication  rules.  In  addition,  many  ways  of  signaling  through 
text  (e.g.,  modulating  the  space  width)  would  be  extremely 
difficult  to  detect  by  automatic  classifiers  or  downgrades. 
Although  some  participants  believed  it  might  be  reasonable 
to  assume  that  Classi  would  not  operate  in  a  hostile  envi¬ 
ronment,  these  issues  underscore  the  need  to  investigate 
how  to  achieve  a  high  degree  of  assurance  for  AI  systems, 
such  as  Classi,  that  are  used  to  assign  access  classes  to  text 
or  data.  In  the  absensc  of  high  assurance,  a  human  may 
still  be  needed  in  the  loop,  but,  as  the  group  noted,  putting 
a  human  in  the  loop  is  not  an  answer  cither. 

7  Assurance 

7.1  Balanced  Assurance 

Balanced  assurance  has  been  proposed  in  SeaView  (and 
earlier  by  Roger  Schell  of  Gemini  Computers  and  others 
in  formulating  the  Trusted  Network  Interpretation  [  13])  as 
a  means  of  achieving  Al  (oi  B3  or  B2)  assurance  for  the 
system  as  a  whole  by  applying  all  the  Al  (or  B3  or  B2)  as¬ 
surance  techniques  to  the  portion  of  the  system  enforcing 
mandatory  security  and  less  stringent  assurance  measures 
(comparable  to  Class  C2)  to  those  portions  of  the  TCB  en¬ 
forcing  the  less  critical  security  properties,  such  as  database 
consistency  and  discretionary  access  control  [14].  Accord¬ 
ing  to  Schell,  the  idea  of  applying  balanced  assurance  to 
database  systems  stems  from  a  qu  »stion  raised  by  Dorothy 
Denning  at  the  NCSC’s  invitational  Workshop  on  Database 
Security  in  June  1986  ( 1J>] .  Her  contention  was  that  al¬ 
though  views  are  not  appropriate  as  objects  for  mandatory 
security,  views  could  provide  an  extremely  flexible  mecha¬ 
nism  for  discretionary  security,  especially  for  content-  and 
context-dependent  controls.  At  that  time,  she  felt  strongly 
that  the  use  of  views  for  discretionary  security  in  IBM’s 
System  R  [16]  pointed  to  the  direction  that  database  sys- 


189 


terns  would  take  in  the  future  and  that  requiring  A1  assur¬ 
ance  for  discretionary  security  mechanisms  would  rule  out 
view-based  discretionary  controls  because  of  their  complex¬ 
ity.  (Denning  has  since  begun  to  examine  whether  discre¬ 
tionary  controls  should  be  applied  to  storage  objects  rather 
than  to  views  for  some  applications.) 

The  argument  for  balanced  assurance  is  as  follows.  A 
system  X  meets  the  assurance  requirements  for  Class  C2 
and  operates  in  system-high  mode  at  class  e.  Suppose  sys¬ 
tem  X  is  connected  across  a  single-level  connection  at  class 
c  with  system  V,  an  A1  system  whose  range  of  classes  in¬ 
cludes  c.  In  the  resultant  system,  we  have  At  assurance 
that  only  information  whose  class  is  dominated  by  c  can 
flow  to  system  X.  Because  system  X'a  C2  assurance  was 
good  enough  to  enforce  its  (nonmandatory)  security  policies 
before  the  connection  was  made,  no  further  threat  is  coun¬ 
tered  by  applying  additional  assurance  techniques,  such  as 
formal  analysis,  to  the  C2  system.  Thus,  the  overall  sys¬ 
tem  (comprising  the  A1  and  C2  components)  should  meet 
th"  assurance  requirements  for  Class  Al,  If  we  consider  a 
Claes  Al  multilevel  database  system  to  be  a  collection  of 
several  single-level  “virtual  machines”  (one  for  each  class), 
each  enforcing  discretionary  and  consistency  policies,  each 
having  C2  assurance,  and  each  executing  on  an  underlying 
Al  mandatory  security  kernel,  the  balanced  assurance  ar¬ 
gument  wouia  oe  mat  the  overall  system  is  Al.  The  C2 
portions  of  the  system  are  constrained  by  the  underlying 
mandatory  security  kernel  and  thus  can  introduce  no  com¬ 
promise  to  mandatory  security. 

The  discussion  of  balanced  assurance,  led  by  Bill  Shock- 
ley  of  Gemini,  was  animated.  Although  some  believed  that 
users  will  not  want  systems  that  are  “Al  here  and  C2 
there,"  Shockley  emhasized  that  balanced  assurance  does 
not  mean  just  “slapping  a  C2  on  an  Al.”  Rather,  the  over¬ 
all  system  should  be  well  engineered.  Just  what  system 
engineering  requirements  should  be  adhered  to  still  needs 
to  be  defined. 

7.2  TCB  Subsetting 

The  balanced  assurance  argument  goes  hand  in  hand  with 
the  TCB  subsetting  argument  (17).  TCB  subsetting  is  a 
term  introduced  by  Bill  Shockley,  drawing  on  earlier  work 
by  Marv  Schaefer  and  Roger  Schell  on  extensible  TCBs  (18), 
to  mean  structuring  a  TCB  in  layers,  with  each  layer  enforc¬ 
ing  its  own  policies  and  with  each  layer  constrained  by  the 
pol'cles  enforced  by  the  lower  layers.  If  a  previously  evalu¬ 
ated  TCB  Is  used  for  the  lowest  layer,  as  in  SeaView’s  use 
of  GEMSOS,  TCB  subsetting  allows  the  addition  of  a  new 
layer  to  form  an  extended  TCB  without  disturbing  the  ba¬ 
sis  for  the  evaluation  of  the  original  TCB.  With  this  layered 
approach,  a  mandatory  security  kernel  as  the  lowest  layer 
enforces  mandatory  security  for  the  entire  system  without 
the  need  to  verify  the  entire  extended  TCB  for  mandatory 
security. 

Several  workshop  participants  argued  that  TCB  sub- 
setting  is  the  way  of  the  future.  The  TCB  subsetting 
approach  allows  third-party  vendors  to  build  independent 
products  to  extend  a  system’s  TCB  to  enforce  additional 
non-mandatory  policy  without  having  to  verify  mandatory 
security.  TCB  subsetting  abo  allows  one  to  build  a  sys¬ 
tem  that  enforces  different  discretionary  policies  in  differ¬ 
ent  domains,  with  the  underlying  kernel  providing  domain 
isolation.  For  example,  a  mandatory  security  kernel  could 
support  three  different  domains  —  one  for  a  file  system,  one 


for  a  database  system,  and  one  for  a  mail  system  —  with 
each  domain  enforcing  its  own  discretionary  security  pol¬ 
icy.  Thus,  an  underlying  global  discretionary  policy  need 
not  be  enforced  by  the  operating  system. 

7.3  Layered  TCB 

The  Unisys  project  is  designing  a  layered  TCB  (composed 
of  a  system  TCB  plus  component  TCBs).  Honeywell’s  LDV 
also  has  a  layered  TCB,  with  the  LOCK  TCB  underneath, 
plus  an  additional  LDV  TCB  on  top,  designed  to  facilitate 
proving  properties  about  the  LDV  TCB.  SeaView  has  a 
layered  TCB,  with  the  GEMSOS  TCB  undorneath  and  a 
lesser-assurance  TCB  enforcing  database  consistency  prop¬ 
erties  and  discretionary  access  controls  on  views  and  mul¬ 
tilevel  relations  on  top.  Some  participants  were  concerned 
about  enforcing  the  nonbypassability  of  the  database  sys¬ 
tem.  LDV  uses  the  LOCK  type-enforcement  mechanirm 
and  “trusted  pipelines”  for  this;  SeaView  uses  the  GEM¬ 
SOS  ring  mechanism.  Other  participants  pointed  out  that 
a  Biba  integrity  category  could  also  be  used.  Another  al¬ 
ternative  is  a  dedicated  database  machine.  Several  noted 
that  discretionary  access  controls  in  the  underlying  TCB 
could  not  guarantee  that  the  database  system  could  not  be 
bypassed. 

8  New  Approaches 

The  group  discussed  several  new  approaches  to  multilevel 
database  systems.  George  Gajnak  of  AOG  described  a  secu¬ 
rity  model  for  entity-relationship  systems  and  engendered 
a  lively  discussion  contrasting  his  work  with  the  SeaView 
model.  Gajnak  introduced  what  he  called  the  determinacy 
principle,  which  requires  that  references  be  nonambiguous. 
He  used  an  example  to  demonstrate  the  principal  advantage 
of  his  secure  E-R  model  over  a  relational  model,  namely, 
that  in  the  relational  model,  one  cannot  avoid  referential 
ambiguity  when  data  is  polyinstantiated.  The  problem  is 
due  to  a  fundamental  weakness  of  the  relational  model.  Be¬ 
cause  the  relational  model  matches  on  value  rather  than  es¬ 
tablishing  specific  references  for  specific  entities,  when  new 
data  are  added,  new  possibly  inappropriate  relationships 
are  automatically  formed.  In  AOG’s  secure  E-R  model, 
even  though  entities  may  be  polyinstantiated,  no  referential 
ambiguity  exists  because  a  reference  is  not  a  relationship 
but  applies  to  a  particular  tuple  or  value  in  the  entity  -  that 
is,  an  explicit  link  to  particular  data  is  required.  Thus,  un¬ 
like  the  relational  model,  when  a  new  entity  is  added  in  the 
E-R  model,  the  old  references  do  not  apply  to  it.  In  the 
relational  model,  the  higher  the  access  class,  the  greater 
the  ambiguity. 

Another  of  the  new  approaches  was  presented  by  Bha- 
vani  Thuraislngham  of  Honeywell.  In  her  talk,  “Founda¬ 
tions  of  Multilevel  Databases,”  she  advocated  applying  for¬ 
mal  logic  to  develop  a  theoretical  foundation  for  multilevel 
databases.  Cathy  Meadows  discussed  multilevel  security 
for  an  cbject-oriented  data  model  and  sketched  how  NRL’s 
Secure  Military  Message  System  might  be  modeled  as  an 
object-oriented  system. 

Rae  Burns  presented  what  she  calls  a  practical  database 
security  policy,  that  calls  for  certain  features  to  be  built  into 
multilevel  database  systems  to  accommodate  the  require¬ 
ments  of  the  applications  that  will  be  built  on  top  of  them. 
These  features  include  an  interface  for  trusted  applications 
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that,  would  provide  trusted  labels  for  elements  and/or  tu¬ 
ples  (depending  on  the  classification  granularity),  transac¬ 
tion  authorization  controls  (as  in  the  Clark-Wilson  model), 
automatic  classification  and  saniti.'.ation,  automatic  en¬ 
forcement  of  classification  of  related  data  based  on  foreign 
keys  (that  is,  the  data  that  the  foreign  key  refers  to  are 
constrained  to  be  at  least  as  high  as  the  foreign  key  itself), 
r.o  polyinstantiation,  and  enforcement  of  entity  and  refer¬ 
ential  integrity  inside  the  DBMS  kernel  (that  is,  ordinary 
entity  and  referential  integrity,  not  multilevel  versions  of 
them).  For  example,  she  feels  that  if  a  low  user  tries  to 
insert  a  tuple  when  a  high  tuple  with  she  same  key  already 
exists,  he  or  she  should  be  told  that  '.he  data  cannot  be  ac¬ 
cepted.  Although  some  of  these  requirements  (namely,  the 
automatic  classification  of  related  data,  the  prohibition  of 
polyinstantiation,  and  the  enforcement  of  ordinary  entity 
integrity)  may  be  in  conflict  with  multilevel  security  and 
lead  to  potentially  high-bandwidth  covert  channels,  Burns 
said  she  would  rather  live  with  the  covert  channels  than 
inflict  polyinstantiation  on  the  applications  with  which  she 
is  familiar. 

On  the  whole,  the  group  had  many  reservations  about 
her  requirements.  First,  automatic  initial  classification  of 
data  must  be  distinguished  from  automatic  reclassification: 
Automatically  reclassifying  related  data  can  create  high- 
bandwidth  covert  channels.  Also,  the  advantage  of  polyin- 
stantiation  is  that  low  subjects  need  no  access  whatsoever 
to  high  data;  thus,  rejecting  a  low  subject’s  request  based 
on  the  existence  of  high  data  is  not  even  an  option.  More¬ 
over,  the  existence  of  multilevel  secure  database  systems 
may  change  the  way  world  does  its  business.  Instead  of 
mimicking  the  current  way  of  doing  business  in  the  ex¬ 
ternal  environment  and  translati  g  the  paper  world’s  low- 
bandwidth  information  flow  channels  into  high-bandwidth 
covert  channels,  we  should  be  building  secure  systems  and 
requiring  the  external  environment  to  adjust  to  achieve  se- 
operation.  In  other  words,  today’s  research  projects 

-Id  create  possibilities  for  the  future  rather  than  build 
■  ound  today’s  limitations. 

9  Classifying  Metadata 

The  group  discussed  how  to  classify  metadata  and  views. 
The  group  examined  whether  a  query  is  a  labeled  object 
and  whether  the  data  in  a  query,  especially  strings  entered 
by  the  user,  have  classifications.  The  group  agreed  that  a 
query  is  a  labeled  object  classified  at  the  subject  class  and 
that  a  user  operating  in  a  range  of  levels  should  be  able  to 
specify  the  level  of  the  query.  Then  the  level  of  the  tuples 
returned  should  dominate  the  level  of  the  query  object.  The 
group  also  agreed  that  a  view  definition  is  a  labeled  object 
with  a  classification  at  least  as  great  as  any  relation  or  view 
it  refers  to,  as  in  SeaView,  and  possibly  also  dominating  the 
level  of  any  strings  it  contains  or  the  level  of  the  subject 
that  created  the  definition.  A  classified  view  definition  is 
like  a  classified  program:  In  order  for  a  subject  to  execute 
the  query  defining  the  view,  its  access  class  must  dominate 
the  class  of  the  view  definition.  The  group  also  debated 
whether  the  level  of  the  view  definition  or  of  the  strings 
in  the  view  definition  should  contribute  to  the  level  of  the 
result  of  any  query  using  the  view.  In  the  Unisys  system, 
the  level  of  the  view  definition  is  a  lower  bound  for  the  result 
of  any  query  against  the  view.  In  addition,  in  the  Unisys 
system,  if  a  user  specifies  a  level  Ll  for  a  tuple  to  be  inserted 


through  a  view  V  whose  definition  has  access  class  L2  > 
Ll,  the  operation  is  denied  because  there  is  information 
flow  from  the  view  definition  to  the  data  inserted  through 
the  view.  Consequently,  SECRET  tuples  cannot  be  inserted 
through  a  TOP-fECRET  view,  for  example. 

Asked  who  should  be  permitted  to  browse  the  descrip¬ 
tions  of  relations  and  views  in  the  database,  the  group 
agreed  that  if  a  user  is  not  cleared  for  a  relation  or  view, 
he  or  she  should  not  be  able  to  read  the  description  for  the 
relation  oi  view  (the  description  is  the  names  and  types 
of  attributes,  as  opposed  to  a  view  definition,  which  is  the 
query  defining  the  view).  The  group  also  believed  that  if  a 
user  does  not  have  discretionary  authorization  for  a  relation 
or  view,  the  user  should  not  be  able  to  read  the  descrip¬ 
tion  (because  it  would  violate  least  privilege).  A  separate 
‘browse’  or  ‘list’  access  mode,  as  in  SeaView,  can  be  used 
to  allow  users  to  be  independently  authorized  to  list  the 
descriptions  of  relations  and  views  they  are  cleared  to  see 
in  a  database. 

The  group  agreed  that  metadata  (such  as  integrity  con¬ 
straints  and  classification  constraints)  are  classified  at  least 
as  high  as  the  relation(s)  to  which  they  refer, 

10  Conclusions 

The  state  of  the  art  in  multilevel  database  security  has  ad¬ 
vanced  considerably  since  the  Air  Force  Summer  Study, 
and  the  past  few  years  have  in  fact  made  the  findings  of 
that  study  obsolete.  Projects  such  as  SeaView,  originally 
inspired  by  the  Summer  Study,  have  demonstrated  that 
many  of  the  directions  suggested  by  that  study  are  un¬ 
workable.  This  is  not  bad  news,  however,  because  today’s 
research  projects  have  made  possible  the  introduction  of 
high-assurance  multilevel  database  products  in  the  near  fu¬ 
ture.  Moreover,  the  new  research  directions  suggested  at 
this  workshop  open  up  exciting  new  possibilities  for  the 
future. 

The  general  consensus  was  that  this  was  an  extremely 
productive  and  successful  workshop.  Proceedings  of  the 
workshop  will  bo  published  at  the  end  of  this  year.  Readers 
wishing  to  purchase  copies  of  the  proceedings  should  send 
their  names  to  Teresa  bunt,  SRI  International,  Computer 
Science  Labor;  ory,  333  Ravenswood  Ave.,  Menlo  Park, 
CA  94025.  second  workshop  is  planned  for  February 
or  March  1989. 
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Appendix: 

The  Homework  Problem 

HI-TECH  University  Final  Exam  (Take  Home) 

Database  Security  1  Due  Date:  April  1,  1988 

The  example  database  for  this  exam  is  taken  from  our  pri¬ 
mary  textbook,  Date’s  An  Introduction  to  Database  Sys¬ 
tems,  Volume  1,  Chapters  16  and  27  (p.  279  in  the  third 
edition),  Addison- Wesley,  1981.  The  description  from  the 
text  is  as  follows: 

In  this  example  we  are  assuming  that  the  com¬ 
pany  maintains  an  education  department  whose 
function  is  to  run  a  number  of  training  courses. 

Each  course  is  offered  at  a  number  of  different 
locations  within  the  company.  The  database 
contains  details  both  of  offerings  already  given 
and  of  offerings  scheduled  to  be  given  in  the  fu¬ 
ture.  The  details  are  as  follows: 

»  For  each  course:  course  number  (unique), 
course  title,  course  description,  details  of 
prerequisite  courses  (if  any),  and  details  of 
all  offerings  (past  and  planned); 

•  For  each  prerequisite  course  for  a  given 
course:  course  number  and  title; 

•  For  each  offering  of  a  given  course:  date, 
location,  formate  (e.g.,  full-time  or  half¬ 
time),  details  of  all  teachers,  and  details  of 
all  students; 

•  For  each  teacher  of  a  given  offering:  em¬ 
ployee  number  and  name; 

•  For  each  student  of  a  given  offering:  em¬ 
ployee  number,  name,  and  grade. 

Each  exam  question  is  based  on  this  database  application; 
each  succeeding  questions  builds  on  the  answers  to  the  prior 
questions.  You  are  advised  to  read  the  entire  exam  first  and 
then  to  proceed  to  answer  each  question  in  turn. 

1,  (5  pts)  Develop  a  data  model  diagram  or  an  entity- 
relationship  diagram  for  the  education  database  de¬ 
scribed  above. 
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2.  (5  pts)  Design  a  relational  schema  for  the  database. 
Include  primary  keys,  foreign  keys,  and  attribute  data 
types.  Use  an  “SQI.-like”  syntax,  with  any  extensions 
that  seem  appropriate. 

3.  (30  pts)  Using  an  “SQL-like”  syntax,  express  the  fol¬ 
lowing  application  security  policy,  based  on  the  re¬ 
lational  schema  developed  in  question  2.  The  policy 
statements  assume  only  two  levels  of  security:  UN¬ 
CLASSIFIED  and  SECRET. 

(a)  Some  courses  are  SECRET;  all  information  about 
a  SECRET  course  (including  details  of  offerings, 
teachers,  and  students)  is  SECRET. 

(b)  All  course  offerings  at  location  “Pentagon"  are 
SECRET. 

(c)  If  a  course  has  a  SECRET  prerequisite,  then  the 
course  is  also  SECRET. 

(d)  Course  information  may  be  inserted,  modified, 
or  deleted  only  by  a  course  administrator.  At 
least  one  course  administrator  is  cleared  for  SE¬ 
CRET  data. 

(e)  A  course  clerk  enters  offering,  enrollment  and 
student  grade  information;  however,  once  en¬ 
tered  into  the  database,  such  information  may 
be  modified  or  deleted  only  by  a  course  adminis¬ 
trator.  No  course  clerks  are  cleared  for  SECRET 
data. 

(f)  If  a  student  has  taken  a  SECRET  offering,  then 
the  student's  transcript  is  SECRET. 

(g)  A  student’s  grade  point  average  (GPA)  is  UN¬ 
CLASSIFIED  but  may  be  accessed  only  by  a 
course  administrator. 

4.  (10  pts)  Briefly  discuss  the  implications  and  ambigu¬ 
ities  of  at  least  two  of  the  security  policy  statements 
above. 

5.  (10  pts)  Specify  two  additional,  or  alternative,  secu¬ 
rity  policy  statements  that  would  be  appropriate  for 
the  corporate  education  database. 

6.  (40  pts)  Informally  map  four  of  the  application- 
specific  security  policy  statements  from  the  previous 
questions  (3  Rnd  5)  to  a  general  DBMS  security  pol¬ 
icy  model.  Discuss  the  relative  success  of  the  DBMS 
model  in  expressing  and  enforcing  the  application- 
specific  policy.  Address  at  least  one  data  entry  oper¬ 
ation. 

EXTRA  CREDIT! 

The  extra  credit  question  is  based  on  the  article  by 
Morgenstern  (“Controlling  Logical  Inference  in  Multilevel 
Database  Systems,”  Proceedings  of  the  198S  IEEE  Sympo¬ 
sium  on  Security  and  Privacy,  April  1988,  pp.  245-255). 

Define  the  sphere  of  influence  (SOI)  for  the  corporate  ed¬ 
ucation  database.  Localize  and  describe  the  sources  of  in¬ 
ference  channels,  Revise  the  database  schema  design  and 
security  statements  as  needed  to  remove  any  open  inference 
channels. 
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Introduction 

This  paper  provides  a  snapshot  of  ongoing  support  lor  the 
Nnlioiuil  C-ompiiivr  Security  Center  to  produce  Environments 
Guide -lines  for  i  he  Trusted  Network  Interpretation  of  (lie  Trusted 
Computer  System  Kvnlilnlion  Critrmi  (TNI)  |lj.  'Pile  TNI 
Kiivironimhls  (iuideline.s  (TNIKG)  document  identifies  minimum 
security  prut  cel  ion  required  in  different  network  environ  men  Us.  Its 
relation  to  computer  networks  |  mm  lie  Is  the  TCSKC  KhV  iron  ment-s 
Ciuidelines  2i  relation  (o stand-alone1  computer  systems.  The  definition 
of  envimnnienl  is  the  same  in  liot-li  documents:  “'Phe  aggregate  of 
external  eirciiiu*l-unces,  eomlil  ions,  and  events  that  affect-  the 
development,  operation,  and  main  ten  since  of  a  system.” 

Background 

'Phis  section  briefly  describes  Depaii-ineiP  of  Defense  computer 
and  network  gilidane*  and  processes. 

The  NC  SC  is  responsible  for  establishing  and  muiniaiiiing 
tee)  mica  I  standards  and  criteria  for  the  evaluation  of  trusted  computer 
systems.  As  pari  of  tliis  responsibility,  the  NCSO  is  developing 
guidance  on  how  new  security  technology  should  be  used.  There  are 
two  objectors  to  this  guidance: 

n.  Establishing  a  metric  for  categorizing  systems  according  to  the 
security  protection  they  provide. 

h.  Identifying  the  minimum  security  protection  required  in  different 
environments. 

'Phe  Trusted  Computer  System  Evaluation  Criteria  (TCSKC)  |tf) 
satisfy  the  first  objective  by  categorizing  computer  systems  into 
hierarchical  classes  based  oil  evaluation  of  their  security  features  and 
iissiuaiiees.  'Phe  TCSKC  Environments  Guidelines  |2|  satisfy  the  second 
objective  by  identifying  the  minimum  clnsses  appropriate  for  systems  in 
diffei i’ll i  risk  environments,  These  two  documents,  however,  nppiy  to 
stand-alone  computer  systems. 

The  TNI  :  1 .  satisfies  the  first  objective  by  interpreting  the 
T(  ’SIX’  |.i|  networks  'Phe  TNI  also  provides  guidance  for  selecting 
and  specifying  oilier  security  services  (e  g.,  com  imiliica*  ions  integrity, 
deliiu I  of  servic.  I r aus mission  security).  The  I'M  divides  computer* 
oimutuiucniioii.s  networks  into  two  gnwijm:  those  which  can  be 
evaluate*!  as  a  Sin  flic  Trusted  Syttlcm  (also  e  died  a  network  system) 
according  t«>  Dart  I.  and  tlnwe  winch  cannot.  Fan  |  of  the  'PNI  is  an 
intripiruiion  of  the  stnnd-nloiit*  operating  system  orient  at  ion  of  the 
TCSKC  for  networks.  Those  network  systems  can  range  from  isolated 
local  area  networks  to  wide-area  Intel  net  works  and  tire  accredited  as 
single  rill  Hies  by  a  single  accredit  mg  authority.  Those  eompllter- 
comiiiLiiiirut ions  complexes  that  cannot  be  e\ ablated  using  I’art  I  of  l he 
'PNI  an-  called  interconnected  Sepanilcly  Accredited  Automated 
Info  nnatmn  Sy/itc/tis,  or  Interconnected  AlS.  Intereoimccted  A  IS 
contain  multiple  systems  (some  of  which  may  be  tiusted)  which  have 
been  independently  accredited.  In  these  interconnected  AIS  networks 
the  accreditor(s)  may  la*  fin  red  to  accept  the  risk  of  assessing  network 
security  without  the  benefit  of  an  evaluation  against  the  TCSKC 
principh-s  contained  in  Part  I  of  the  'PNI. 

Purpose 

'Ihe  overall  purpose  of  the  TNI  KG  is  to  provide  guidance  to 
program  managers,  system  security  officers  (SSOJ,  designated 
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approving  authorities  (I)AA),  and  others  concerned  with  selecting  and 
operating  trusted  computer  networks.  For  brevity,  this  audience  is 
referred  to  as  security  malingers. 

Since  the  TNI  treats  network  systems  and  interconnected  AN 
differently,  but  includes  other  security  services  which  are  applicable  to 
both  views,  the  TNIKG  lies  several  particular  purposes.  For  network 
systems,  one  purjxwe  of  the  TNIKG  is  to  provide  security  manager* 
with  guidance  as  similar  as  |xxvsible  to  the  TCSKC  Environments 
Guidelines.  For  security  managers  of  interconnected  AIS,  one  purpose 
is  to  explain  when  systems  can  be  interconnected  and  what  data 
sensitivity  levels  arc  permitted  on  the  connections.  For  all  security 
managers,  one  purpose  is  to  provide  guidance  as  to  which  other 
security  services  (from  Fart  II  of  the  TNI)  arc  required  lor  then- 
specific  network.  Since  the  guidance  for  the  Inst  two  purposes  must  In* 
less  .structured  than  TUSKG  guidance,  another  purpose  is  to  give 
security  managers  sufficient  material  to  follow  the  guidance. 

Scope 

The  TNIKG  describes  an  environmental  assessment  process  that 
determines  the  minimum  level  of  trust  recommended  for  specific 
network  environments.  'Phe  primary  locus  of  this  document  (and  also 
of  the  TNI)  is  on  the  hardware/ 'soft ware  aspects  of  security:  therefore, 
neither  the  TNIKG  nor  the  'TNI  addresses  all  the  security  requirements 
that  may  be  imposed  on  a  network.  Depending  on  the  particular 
environment,  communications  security  (GOMSKC),  emanations 
security,  physic'*  security,  personnel  security,  administrative  security, 
ami  other  in  for  u.n  lion  security  (INFOSKC)  measures  or  safeguards 
may  also  be  required.  This  document  applies  to  DoD  networks  that 
are  entrusted  with  the  protection  of  information,  regardless  of  whether 
or  not  that  information  is  classified,  sensitive,  or  national  security 
related. 

Two  Views  of  the  Network  Environment 

We  begin  by  considering  a  series  of  increasingly  complex 
net  works,  starting  with  an  Automated  Informalinn  System  (AN),  and 
ending  with  complex  networks  of  interconnected  systems.  This  section 
enables  security  managers  to  determine  whether  to  treat  their  network 
as  a  network  system  or  as  an  interconnected  AIS. 

Individual  Automated  Information  System  (AIS) 

The  term  Automated  Information  System  (AIS)  is  used  in  several 
wavs.  Two  definitions  bound  the  uses,  '['he  first,  narrower,  definition 
which  comes  from  the  'PNI  states  that  AlS  are  "trusted  commercially 
available  automatic  data  processing  (ADF)  systems. ”  The  TNIKG 
calls  such  AIS  individual  AlS,  An  individual  AlS  may  be  formally 
evaluated  against  the  TCSKC  and  given  an  evaluation  class.  An 
individual  AlS  has  a  coherent  security  architecture  and  design,  and  it 
has  a  trusted  computing  base  (TUB). 

The  second  broader  definition,  which  comes  from  l)ol>  Directive 
5200.28  (I),  Security  lir.yuiremenis  for  Automated  Information 
System*,  states  that  an  AlS  is  “an  assembly  o!  computer  hardware1, 
software,  and/or  firmware  configured  to  collect,  create,  com  it  um  irate, 
compute,  disseminate,  process,  store,  and/or  control  data  or 
information.”  The  directive  also  states  that  AN  include  ‘'stand-alone 
systems,  communications  systems,  and  computer  network  systems  ...; 
associated  peripheral  devices  and  software;  process  control  computers; 
embedded  computer  systems;  communications  switching  computers; 
personal  computers;  intelligent  terminals;  word  processors;  office 
automation  systems;  application  and  operating  system  software; 
firmware1;  and  other  AlS  technologies....” 
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The  reader  is  cautioned  that,  any  particular  use  of  the  term  AiS 
may  apply  only  to  an  individual  AIS,  to  any  system  satisfying  the 
broader  definition,  or  to  some,  perhaps  unspecified,  subset  of  the 
systems  satisfying  the  broader  definition. 

The  Single  Network  System 

A  more  complex  environment,  including  several  AIS  networked 
together  with  a  coheres',  network  security  architecture  and  design,  is 
called  tt  network  system  or  a  single  trusted  system.  A  network  system 
has  a  network  trusted  computer  base  (NTCB).  The  NTCB  is 
partitioned  among  the  components  of  the  network,  where  a  component 
is  any  part  of  a  system  that-,  taken  by  itself,  provides  all  or  part  of  the 
required  functionality.  A  component  may  or  may  not  have  an  NTC'B 
partition.  The  essential  point  is  that  the  NTCB  as  a  whole  satisfies 
(he  security  architecture  and  design.  Network  systems  may  be 
evaluated  against  Part  1  of  the  TNI  and  may  he  given  class  evaluations 
like  individual  AIS  evaluated  against  Lite  TCSEC. 

Network  systems  commonly  provide  security  services  that 
normally  do  not  arise  in  individual  AISs.  These  include  communication 
integrity,  denial  of  service  countermeasures,  compromise  protection, 
and  suppoi  five  primitives  such  as  encryption  and  protocols.  These 
services  cannot  lie  given  a  security  rating  class.  They  are,  instead, 
evaluated  against  Part  II  of  the  TNI.  The  Part  II  evaluation  is 
dependent  on  the  Part  1  evaluation,  in  the  sense  that  a  Part  II 
evaluation  has  low  assurance  if  the  Part  1  .iting  class  is  low. 

The  type  of  network  that  may  lie  defined  as  a  network  system 
includes,  for  example,  a  group  cf  departmental  AIS  having  the  same 
architecture  connected  by  a  local  area  network.  Any  component  that 
does  not  enforce  the  full  implementation  of  all  policies  must  lie 
evaluated  as  u  component,  not  us  a  full  network  system. 

Interconnected  AIS 

The  most  complex  environment  is  referred  to  n*  interconnected 
accredited  AIS.  ™  simply,  interconnected  AIS.  The  term  AIS,  in  this 
context,  may  lie  an  ndividual  AIS,  a  network  system  or  even  an 
interconnected  AIS;  ;.e„  it  may  he  any  system  satisfying  the  broader 
definition  given  above  which  has  communication  capability  and  which 
has  been  previously  accredited.  Another  way  of  stating  the  difference 
between  network  systems  and  interconnected  AIS  is  that  a  network 
system  exhibits  a  comtn-m  level  of  trust  at  ail  external  interfaces,  white 
interconnected  AIS  do  not.  Therefore,  interconnected  AIS  cannot  be 
evaluated  and  given  roting  classes.  Instead,  they  are  accredited  using 
Appendix  of  the  TNI  to  determine  what  sensitivity  levels  can  be 
exchanged  between  the  AIS.  Part  II  evaluation  applies  to  all  networks. 

There  are  several  circumstances  that  would  dictate  using  the 
interconnected  AIS  view,  instead  of  the  single  trusted  system  view. 
These  include  connecting  AIS  with  different  architectures,  connecting 
with  an  individual  AIS  that  has  not  been  evaluated,  and  connecting 
two  previously  accredited  AISs.  There  are  oilier  circumstances  where 
the  cvalualor/accreditor  has  a  choice:  consider  one  AIS  a  component 
of  another  AIS.  and  evaluate  the  whole  system;  or  evaluate  each  AIS 
separately  and  connect  them  using  the  interconnection  rules  (Appendix 
C  of  the  TNI). 

Security  Requirement  Determination 

The  TNIEG  guides  the  security  manager  in  determining  the 
recommended  minimum  security  requirements  for  the  network. 
Following  the  TNI.  the  security  requirement  computation  is  divided 
into  two  parts.  During  the  first  part,  the  security  manager  determines 
the  type  of  network  and  the  level  of  trust  required  for  the  given 
environment.  For  a  network  that  can  be  evaluated  as  a  single  trusted 
system,  the  output  is  a  TCSEC  class.  For  a  network  that  cannot  be 
evaluated  us  a  single  trusted  system,  the  output  will  be  guidance 
concerning  interconnection  and  a  list  of  other  possible  concerns.  During 
the  second  part,  the  security  manager  determines  requirements  for 
additional  security  services.  The  second  part  provides  a  list  of 
functionalities,  strengths  of  mechanisms,  and  assurances  for  TNI  Part 
II  concerns. 


Protocol  Layer  Approach 

The  TNIEG  use  the  Open  Systems  Interconnection  (OSI) 
reference  model  j5]  because  it  provides  a  well-understood  terminology. 
The  TNIEG,  however,  arc  independent  of  the  actual  protocol  referen-c 
model  used;  they  are  applicable  to  all  protocols. 

A  network  system  must  fully  implement  ali  policies;  but  its 
NTCB  need  not  be  implemented  in  all  protocol  layers.  The  precise 
security  services  and  their  granularity  will  depend  on  the  highest 
protocol  layer  at  which  the  NTCB  is  implemented.  For  example,  a 
Network  Layer  (layer  3)  network  such  as  DDN  can,  at  best,  distinguish 
among  host  addresses  in  providing  discretionary  access  control.  The 
Secure  Data  Network  System  (SDNS)  [8],  currently  being  designed,  is 
expected  to  provide  end-to-end  encryption  (E3)  systems  at  the 
Network,  Transport  and  Application  Layer.  A  proposed  electronic 
mail  specification  expects  t.o  use  SDNS  at  the  Application  Layer  to 
provide  access  control  that  can  distinguish  among  individual  users. 

The  network  system  evaluator  may  be  faced  with  the  choice  of 
evauating  a  single  trusted  system  or  accrediting  the  interconnection  of 
AIS.  There  is  an  advantage  to  evaluating  a  group  of  components  as  a 
network  system:  the  design  may  provide  a  distributed  NTCB  where 
one  can  show  that  untrusted  or  less  trusted  components  provide 
services  that  are  not  critical  to  security,  in  contrast,  accrediting 
interconnected  AIS  is  often  constrained  by  the  weakest  (leant  trusted) 
AIS. 

Network  System  Evaluation  Guidance 

This  section  provides  Part  I  environmental  guidelines  for  network 
system,  and  discusses  TNI  Appendix  G  environmental  factors  for 
interconnected  accredited  AIS. 

Single  Trusted  System  View  VVc  now  describe  the  process  lor 
determining  the  appropriate  class  of  network  system  (evaluated  under 
Part  i)  for  a  particular  environment.  They  can  be  evaluated  against 
the  TNI  in  the  same  manner  an  AIS  is  evaluated  against  the  TCSEC, 
and  therefore  the  TCSEC  Environments  Guidelines  applies  its  well. 

To  apply  the  TCSEC  Environments  Guidelines  guidance,  t In¬ 
security  manager  must  determine  the  following: 

a.  Maximum  sensitivity  of  data  processed  by  the  network 

b.  Whether  the  network  security  environment  is  open  or  closed. 
(Open  or  closed  security  environment  refers  to  the  conditions  mulcr 
which  applications  programs  outside  the  TCB  are  developed.  Open 
and  closed  environments  are  defined  in  [2],  ) 

c.  Minimum  clearance  or  author  nation  of  tlu*  network  system  users 
The  term  “user"  must  he  interpreted  broadly  in  a  network  system, 
it  can  include  anyone  who  may  be  able  to  obtain  cleartext 
information  from  u  network  and  will  ordinarily  include  opetational 
personnel  and  users  on  attached  hosts. 

A  table  for  mapping  user  clearance  and  maximum  sensitivity  of 
data  into  Rmin  and  Rmax  respectively  is  contained  in  (2).  The 
algorithm  for  determining  a  Risk  Index  is: 

Risk  Index  =  Rmax  -  Rmin 

Finally,  the  reference  includes  a  table  that  maps  Risk  Index  to  an 
evaluation  class  of  the  TCSEC  [3|. 

A  special  situation  occurs  when  E3  is  present  in  the  network. 
MITRE  believes  that  two  possible  Risk  Indexes  should  be  considered 
and  the  larger  of  the  two  should  be  used  in  determining  the  required 
evaluation  class  for  the  network.  It  should  be  noted,  however,  that. 
NSA  has  not  yet  endorsed  this  approach.1 

As  indicated  in  the  TNI,  an  encryption  mechanism  is  evaluated 
differently  than  other  mechanisms.  Evaluating  encryption  mechanisms 
has  a  long  history  predating  the  TNI,  to  which  the  TNI  defers. 
Evaluation  of  an  encryption  mechanism  is  part  of  communications 
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security  (COMSKC).  Customarily  encryption  mechanisms  I'cciri'  ;i 
rating  ol'  tin*  highest  level  of  classified  information  which  may  be 
protected  using  that  mechanism.  The  TNI  and  the  TNI  lit  J  roqxct 
l-ltsti  rating  scheme.  Therefore,  the*  only  luting  applicable  to  an 
encryption  mechanism  is  the  classification  level  of  the  in  for  mat-ion 
protected.  'Phis  classification  level  also  establishes  the  requirement. 

A  more  complicated  situation  exists  when  K*  is  employed  above 
the  l^ink  Protocol  Layer,  layer  '2.  At  layers  -t  and  *i  the  protocols  are 
concerned  with  the  end  systems  or  intermediate  systems  (e  g..  hosts, 
network  switches)  that  the  links  connect.  Higher  layers  ale  concerned 
with  other  peer  entities. 

An  K‘*  system  may  be  provided  as  (part  of)  an  NT(*H.  When  the 
K*  .system  is  integral  to  the  NTt'H,  it  requires  evaluation  under  the 

TNI* 

The  TNI  evaluation  must  consider  (I)  the  Risk  Index  between  the 
highest  classification  of  data  on  the  network  and  the  lowest  elearnnee 
of  user  with  access  to  the  network,  and  (*2)  the  Risk  Index  for  the 
bypass  in  the  K*  device. 

a.  The  range  of  sensitivity  levels  across  the  network.  This 
Risk  Index  is  concerned  with  the  difference  between  l In*  highest 
level  of  information  on  any  hosl  utt ached  to  the  network  and  (lie 
lowest  eleuratiee  of  a  user  that  could  potentially  get  access  to  t hat- 
information.  Depending  on  the  char  act  eristics  nr  the  network,  tins 
Risk  index  con  Id  In*  larger  or  smaller  than  b.  The  worst  rase 
scenario  occurs  when  some  users  have  lower  eleaiances  than  the 
level  at  which  the  network  backbone  is  physically  protected.  Kor 
exiiinple,  there  are  currently  plans  to  allow  some  uncleared  users  on 
i he  DISNKT  segment  of  the  l)I)N  I7J  which  will  be  physically 
protected  at  the  Secret  level.  In  that  ease,  the  Risk  lnd**x  fur  the 
bypass  works  the  opposile  of  the  normal  ease  the  ciphertext  side 
will  be  the  higher  of  the  two  ratings. 

b.  The  bypass.  In  an  K*  system,  protocol  control  information  must- 
be  sent  around  the  encryption  unit  through  a  bypass.  Tin-  software 
mid  hardware  to  implement  the  bypass  musl  be  trusted  not  to  send 
user  data  through  the  bypass.  A  Risk  Index  call  lx*  computed  based 
on  the  difference  ImMwccii  the  sensitivity  level  of  the  cleartext 
mi- u (nation  and  the  sciisil ivily  level  of  the  tinl rusted  components  of 
tile  iielWoik. 

Tin*  components  which  perform  access  control  and  key 
distribution  must  also  be  concerned  with  tin*  risk  range  since  mipro|xT 
kf\  -.bsll  ibiitioii  could  lead  to  coin  promise  across  1  Jit*  entile  network 

\ n  e( r. uiet »us  disi nlmnoii  could  potentially  permit  tin1  lowest  dcur-d 

iisi  r  i<>  .in-css  the  highest  classification  of  information. 

Automated  Information  Systems  (AIS)  Interconnections 
Intel  <  ohiivr!  mg  .\l*  J"  a  cci  til  lent  ion  and  accreditation  issue  lather 
tliui  i  commercial  prod u«-t  evaluation  issue.  Accreditation  is  the 
itiaiiad  iiu'iit  de«  ls|o||  that  a  sysirni  can  ujicnitc  With  acceptable  risk  in 
;«  paiticular  environment.  »he  T\1F(»  assist  the  security  manager  m 
I  In'  decision  process  The  inlercouiii'cted  AIS  d«»  Hot  receive  ail 

ahi.il  i"n.  instead,  guidance  is  given  to  tie*  act-reditur  of 
lllli  tc  illlierled  AlS 

*1  liree  finiojs  alfect  the  range  of  sensitivity  levels  permitted  l«» 
I  low  o\  er  an  men  oimertMi 

a  Accreditation  range  of  AIS 
b  Ihd i red  uma I  or  I  'indited  u-n;.!  flow 
e  fifobal  considerations 

Accreditation  Range  of  AIS  Kuril  A  Is  is  accredit  ed  to 
operate  ovri  a  particular  range  of  sensitiviiy  levels  These  sensitivity 
levels  are  used  to  determine  if  eoinmuiiicat ion  between  AlS  is 
permitted.  The  accreditation  range  refers  to  the  info; .nation  being 
mmimi  mealed. 

Bidirectional  or  Unidirectional  Flows  If  bidirectional  flow  is 
permitted,  any  pertained  messages  must,  have  a  sensitivity  level  within 
the  accreditation  range  of  each  AIS.  As  explained  below.  J:is  is 
necessary  so  that  messages  c:ut  be  acknowledged  without,  causing  a 
write-down  (viz.  writing  information  at  a  lower  sensitivity  level 


normally  a  security  violation).  It  follows  that  no  information  call  flow 
over  an  interconnection  unless  it  is  m  the  accreditation  range  of  lx>th 
AIS.  For  example,  if  an  AIS  accredited  to  process  TS-U  data  is 
connected  to  ai:  AIS  permitted  to  process  TX-S  data,  information 
permitted  over  the  interconnection  must  be  labeled  TS  or  S. 

When  only  unidirectional  communication  (no  acknowledgement) 
is  utilized  IxMvveon  two  AlS.  write  up  is  permitted  if  each  sensitivity 
level  in  the  source  AlS  is  dominated  by  some  sensitivity  level  in  the 
destination  AIS.  'Pile  receiving  AlS  must  change  the  sensitivity  level  of 
the  message  when  the  message  is  received.  Although  write-up  over  a 
communications  line  is  theoretically  possible,  it  is  not  recommended  in 
general  Iwntise  acknowledgements  of  packets  are  a  write-down  and 
must  be  prohibited.  A  preferred  npproueii  is  to  perform  the  write-up  in 
a  A  IS  which  is  accredited  for  both  levels. 

Global  Considerations  Then*  are  two  global  considerations 
thai  effect  accreditation.  'Pile  first-  is  railed  profniijahnn  of  local  risk, 
discussed  below  in  conjunction  with  accredited  1ml  iinevaluated  AlS. 
The  other  global  consideration  that  may  reduce  tin*  range  further  is  the 
“cascading  problem  '.  The  C  ‘ascad i ng  Froblelu  has  been  iliscussed 
elsewhere  {l.S|  and  will  not  be  addressed  fun  her  in  this  paper. 

When  an  accredited  AIS  is  interconnected  with  :i  second 
accredited  AlS,  the  first  AlS  treats  the  second  ils  a  device  under  the 
TNI.  Kach  AIS  is  responsible  for  importing  and  exporting  only 
messages  which  are  permitted.  The  permissions  depend  on  the 
evaluation  level  and  sensitivity  levels  of  (lie  AIS.  Finally,  the  AIS  must 
be  connected  in  such  a  way  that  no  cascading  problem  exists. 

Managing  Propagation  of  Local  Risk  Connection  of  AlS 
under  the  jurisdiction  of  different  accreditors  requires  agreement 
between  these  accreditor*.  This  agreement  is  recorded  in  a 
Memorandum  of  Agioement  (MOA).  This  MOA  effectively  constitutes 
a  Joint  accredit alioii  of  the  int ercoiiP-*ted  AlS.  Inlereolincctioli  of  two 
or  mole  AIS  under  the  jurisdiction  of  a  single  accreditor  is  a  special 
case,  where  the  MOA  may  by  replaced  by  a  similar  accreditation 
document. 

Homogeneous  Iinevaluated  AlS  Homogeneous  networks  may 
be  formed  by  interconnecting  replicated  identical  unevaltiatcd  AlS.  The 
accrcdiu*!'  may  decide  that  no  propagation  of  local  risk  problem  exists 
within  the  set  of  homogeneous  A  IS  These  homogeneous  uncvalunted 
AlS  may  be  connected  togetiier  in  a  closed  network  community,  thus 
obviating  the  propagation  of  local  risk  problem.  The  dosed  community 
may  be  established  by  physical  connection  or  cryptographic  separation. 

Hierarchically  Related  Accreditors  A*  described  above,  the 
MOA  documents  a  decision  between  peer  accreditors.  Another 
common  ease  is  hierarchically  related  accreditors.  We  will  refer  to  one 
uccrcdih u  as  tlx*  network  accreditor  and  the  other  a*  the  AIS 
accredit! »r.  The  network  accreditor  sets  the  rules  to  which  the  AlS 
accreditor  must  conform.  The  network  accreditor  is  responsible  for 
ensuring  that  eat  h  attaching  AlS  conforms  ,n  this  set  of  rules.  The 
responsibility  of  tin*  network  accreditor  is  analogous  to  a  fiduciary  in 
protecting  tin*  security  of  tin*  alia*  bed  AlS.  The  AlS  accreditor  permits 
his  or  her  AlS  to  attach  to  the  network  bused  on  an  assumption  that 
all  other  attached  AlS  conform  to  the  saint*  set  of  rules.  Iudi\  idual  AIS 
accreditors  do  not  have  generally  have  the  opportunity  to  approve  any 
new  AIS  attaching  to  the  network.  Attaching  a  non-conforming  AlS  to 
the  network  would  jeopardize  I  lie  security  of  all  attached  AlS. 

In  the  special  cast-  i»l  a  roimiioii  user  network  such  as  DON,  it 
limy  be  necessary  to  provide  communications  capabilities  among  non- 
conforming  AlS.  In  general,  these  nmi-conforming  AlS  would  be 
segregated  into  closed  communities  which  could  not  directly 
communicate  with  conforming  AIS.  This  approach  i*  discussed  in 
detail  in  |7 j. 

It  may  be  the  case  that  operational  necessity  overrides  the 
security  needs  of  tin*  attached  AIS.  Tilt*  difficult  question  is;  who 
makes  the  decision?  One  solution  would  be  to  require  approval  bv 
cognizant  authorities  of  all  attached  A  Is  Alternatively,  the  question 
could  In  escalated  to  higher  levels  of  comm  and.  until  a  single  individual 
with  authority  over  all  alt  ached  AIS  w:i*  n-ached  DDN.  for  example, 
requires  J(  S  approval  for  such  attachments. 
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TNI  Pari  II  Security  Service* 

Pall  II  "I  I  Ilf  INI  describe*  additional  seen  Ml*.  eoiiceni-s  and 
xrrvicr'i  (hut  arise  t u  conjunction  uill*  iieluoi L-.  dial  d»*  iml  normal!) 
ai  III  stand-alone  computer*.  :ill<|  hit  not  nll.rililhle  lo  t  Ii<*  detailed 
Iriilui'*  and  Mvuirain  **  etaliiiitidii  preset ihed  by  tin*  IVSKC  These 
•m'i  tints  si  rim's  |i|ii\uic  communications  security.  dinial  of  service. 

^fiinu.  ami  include  *iip|)ortivr  primitives.  such  its 
>,in  typl|uu  mechanism*  and  1 1| Dt m«i|s 

TIi**m-  concern*  >1)1  in  cut  lair  (In*  network  environment  from  (lie 
Mh lid -a l«>nc  computer  tin Iloiumut  Scum*  roller  m*  lake  on  increased 
-irtmluam  e  in  the  mi  Work  etiMloiiim'lll .  ♦'titer  mitiii  ns  do  dot  e\i*|  on 
Htilid-aloih  lojhj.iihis  Soiih*  of  lliesr  concerns  an*  on  (side  (In*  scope 
ol  I ‘:ui  I  olliers  lack  (lie  t  Inure  (mil  ba.*!*  ami  formal  analysis 
under l>  iiiK  Pari  l  l«»i  example.  tin-  Tt'Sl'X*  is  It  used  on  a  well* 
founded  1 1  del  ell*  e  Uiollllo|  rolieept  .Hid  ioniial  diu  Igll  lliel  hixlology. 
(iie|i*  I.s  no  i  «»l||||e|  pal  (  |ii|-  tills  III  Pali  II  oi  tile  TNI.  Pail  11  of  till' 
I’M  deMiiU**  seiviees  |es|n)li-t|V«*  lo  llie.se  coin  eriis  and  provides  a 
(pialilative  nieau.s  oi  evaluating  liieir  effect  ivcinss.  Tills  section 
plovides  nmdam  t  on  selecting  s«‘eunt>  -service*  for  specific  risk  and 
tpplii  Ml  Ions  em  Iioiitiirtils 

Spec  ifir  nt  ion  ami  Evaluation  of  Security  Services 
"tji*  nit  me  and  •■v.iluiinig  Pml  li  -«<cuiiiy  >emcv.s  is  quite  differein 
f|o|n  a  Pari  I  ft  aluiih-.'l.  even  though  Unit  part-*  ale  concerned  u  illi 
l  In-  «;\tn»  ( )•:  .isperts  *»|  •MMiinlv  M-rilM*  or  capabilities  fluid  innaillt . 
sllriulii  •*!  lurrliaiiisin.  .uut  a*-*  lira  me  |o|  i  limit  (lies**  lei  Ins  are 
del  tiled  .u»  l«  ill-  -tt  * 

/’wrii  f  I'uutitu  f»-l«*i*  |n  I  lie  objective  ami  a{>)Moaeii  o|  a  security 
s-iui  e,  H  includes  lent  me*.  filt'c  haliMii.  -tlid  (M'tlnrmulice  MleiliailVe 
*  t  *  I  >  i  *  ■  i*  In-  to  .»•  India*  ( In-  »|csin  d  Iuim  1 1<  »n.«li>  \  mat  he  iiioie  suitable 
111  dllleieni  applh  at  Ml*  ■  lit  KolWlUill* 

>lr>  injih  .i I  nn  r/i«m/w/i  leU-ls  lo  ||"M  wdl  t  speiilic  approach 
in  it  l»»  <\}*e»  I.  d  '*•  idii"n-  its  •»i»jf*ei  it  rs  In  •«»  »|n»*  e;vj*  I  lie  selection 
■t  par  him  ire  -in  It  M*  iiillubci  o|  hits  usi-d  n:  .»  .  Ji<<  k-tiin  >«i  the 
iiiiiiiIh'I  o|  |  •«- 1 1 ii ii> ;«l  a  ais  ir-'-d  in  an  r|i,*it  pt|oii  1 1 >•  •  •(  :t  li  111  can 
-ic.il  it  it  anllt  .tile  t  strength  <*t  inei  li  .till— ll  i 

*  i e|ri s  !«•  ,i  li.ia*  im  In  net  mt;  dial  t !»••  lunt-i  i>>ualiM 

\t  lit  l*«-  .ulll'  t-  d  It  III*  hides  I. impel  I I-I-1 .1  III  I*  Vi  iImIiiIiI  \  ami 

(••sisiaint  again  a  « in  mm •  iilioii  «>|  htpiv  Will  ill"-  i-  *eini.illt 
■  -i  i  .in.  ilt  -e*  iiitoitm*  i  li  *  **  *i  t  testing  s"Mwni«  'iigimei  im*. 
l  dld.il  i"'!  a|,.J  t  ill.  ,.t|«»|i  I Iid  I'duted  appl>  ■  lies  #|'||e  .1 1|:| It  —I—  mat 
1*  (ollll-i!  I  Hit-  I  in  il  *  111*-  I'll-  ai  applied 

Evaluation  Ratings  Pan  II  **  v  ■  hi  ( r  i  n--  1 1  ••  'pi  dp  Pit  •-  a> 
m f ■  1 1  •  -  I  \\  ii  1 1  i  le  l-i<-i  i*>  In.  nit  .|  i ,  •!  i  a  lac-  l*  *  <  I  (  2  )  1 1  ■  'in 

I'-H  !  lie  f'-'ih-  -  I  i  P.iM  11  •  \  du.i»  i>  >n  l«»i  ■■!h*i«*d  -  iui  is  in* 
.■  I.*  i  dlv  -uiiuii  ii  i.-»  it  i|s|hu  i|i»-  |r|  nr-  it  fH>  innntnuni  bin  ■  n  •  I  i/nm/ 

|  i  ..in*  —  -  f  \  i.  .  .  litre  1 1‘ ,  J|i  t  i*.  -(imiii.il  i  .••••!  iisin*  */*•»»>  •  /-r*  >»  nf 

lie  i'  mi  tii't  i-lb  r>  •!  i-  iis«m|  wlil'ii  a  sn  mill  serine  i*.  ii"i  .  »l  I  «•  i  *  •«  I 

I  t  ■  \.ilnnl<  it  »  ■  eit.uti  in’itt  'ik  did  n**l  m«  linh-  in>n*i epudiai i*»n  as 

•III  ol  Its  si-  unit  S*  I  Mil-s  lfi.it  lie!  tt*  >1  k  \l*'i||d  lieliit.ll  ||o|  o||e|ed 
M  It  ll  i  »'s| h'i  i  I..  n- •ii-!e(itnlmi|oii  I’ahle  l  repu»si.|.i.-  i  lie  ct  aliial  ion 
—1  *  >!•  1 1;  *  I*  •  *1  Pill  II  .i.s  ,i  111.1 1 1  >\  ll  idelltiln-s  a  sel  o|  senmlt  s*-rt  e  is 
it  list  .  sj|.  ,  I  ||I  pi  ss||i|e  ....  ,||uaM< 'll  I  .lllK.es  |. . I  «- .*«- 1|  V  |t  i  m  (el  liis.it 

lum  h' ai. dit  \  -r  i f-ut* I  Ii  ■  ■!  in**'  Ii :•  in— ill  and  i.smii  am  e 

Selecting  Scrurily  Sprvict'u  Pul  II  enmnet.iti *  n  ptesi  niative 
s*.  unit  sei%|ifs  i  Iml  an  orcniu/.idoii  mat  ilioose  t*  ■  cm  plot  mi  a 
■>J»**i  |I|«  S||||:|||..!1  \..l  all  se.uillt  M'lViees  will  he  eiplallt  Wllporl.ltil 

I*  -i  i  —  p*'«  ill*  «*nt  imiiriieiit  n<>i  tsill  then  lelatoe  unpoi  tsinec  he  I  In* 
satire  -Wit* *111'.  <l||  1**1  **ll I  «*llVir»  iflMielils  s»e|i*i*t  III*  scciirilt  «ert  ie«*jt  is  ;i 
ruananenn-iu  d**«|si'*n  i> »  which  the  JAIIdi  pi  "tide  input  Tlie'l'NIEli 
lust  aii'li ess  streiigdt  • 'i  met  inuiisjn  ami  ranee,  follow m*  ttluejj 
t|n*|e  .»r>-  :t  senes  .  .f  (|ijes| u>||s  dial  help  tile  serl|rilv  !lt:Ui:WI  sc|ei't 
•lointliuni  !e\e|s  ..f  |in|  t»o|i;i!ll\ 

I  "i  example  "insider  the  selection  ..J  .-..inmiinn  al ions  iiite^ritt 
serin  I**  piotide  prole,  holt  a*ams|  messa*e  stream  in«hiifieat|n|i  \ 
jilll.  I|.  *nal(t  t  d-  •  |sj.  ai  |S  )i  >  srli'i'i  cri.it  det.-rtl'ill  «»n|f.  or  d<-(e<l|o||  alnl 


coiTcrhon.  also  one  limy  select  whether  |t  is  sufficient  to  detect  u 
specific  mimbcf  of  hit  errors,  error  hursts  of  specified  duration,  or  a 
specified  probability  of  an  undetected  error. 

Strength  of  Mechanism  Strength  of  mechanism  is  bused  on  a 
l?i*k  hulex  simihir  to  that  applicable  to  Part  I  of  die  TNI.  One 
significant  difference  is  that  Rtmn  may  be  different  than  the  Part  I 

Tillllr  i 

Evaluation  Structure  for  Network  Security  Services 


Network  Seen  I'll  V  Service 

Crilrlion 

Evidiiidion 

Hiiiiw 

l  ‘ommuuicatioiiK  Integrity 

A  ut  hen  t  lent -ion 

l''iiiict  loiudil  y 

St  rengt  h 

Asstll  aiice 

None  |  present 
None  lo  g<.xjd 
None  to  good 

<  'oiiiiiniitii-s.t  uxi--.  I  n-Id  InlrKrilv 

Kuncl  iotialitv 

Strength 

Assurance 

None  lo  grxxl 
None  to  grxxl 
None  to  good 

\oii-|epu<haHoii 

Fmictioualily 
Sirengi  h 

Assurance 

None  j  present 
Nolle  lo  good 
None  l"  gixwl 

1  >< *11  ill  1  of  Service 

( ’old minty  of  Operal  ion* 

limit  u  laahty 
Slt-iiglli 

A*  urance 

None  to  good 
None  to  grxxl 
None  lo  gixxl 

PfU'Kol  Ihmed  Protection 

|-'iiii<-ti.  >n>ilily 

Siifngdi 

As-.lll-HKf 

Nolle  to  grxid 
None  to  grxxl 
None  to  grxxl 

Network  Management 

l,'iiiii*i  n  mall  I  y 
Simigt  h 

Assurance 

None  |  present 
None  to  good 
Nolle  to  goorj 

(  \ imp iomt.se  Proieciiun 

Data  (  ‘oiilidciil laiil  \ 

I-'uim-i  ii  inalil. 

St  r.-IIK' ll 
.Wiiinm  ■■ 

Nolle  |  plesenl 
Sensitivity  lc\el 
None  to  gixhl 

'I'l  iliTl.-  I  <  '.  .lill.li-lil 

I'liioi  iotialitv 

Strength 

Assurance 

Nolle  j  present 
Sensit  1 V i  1  >  level 
Nolle  lo  giKxl 

Si-lrrl  i\  i-  |(.  .lit  IIIK 

Finn  timmlit  v 

St  u-ngt  h 

Assitl  ance 

Nolle  |  present 
Nolle  l( »  gi  xxl 

None  lo  g<Kxl 

Urn. I  ll  tile  lielWopk  |s  pi .  ■!  ret  ed  ft  t  >111  .imvlil  II  lia  It  I  l|<  i|  l/ed  pt‘1  soils. 

tin-  it  in  •:  i  will  he  h.iM'd  -Mi  die  lowest  cleared  User  In  ueiielal.  tin* 
menus  lli.M  all  end  s\sli*niv  >v\  ilcliin*  pi  on  •smii*.  and  ">niuitiin,.:il  ion* 
lines  uni— |  lie  physically  protected  from  unaul Imn/ed  users  If  tills 
ci»nditi"ii  rail  in  *1  he  met.  eg.  bee  si  line  eniltmil  ItieaMons  lines  an*  in 
areas  open  to  the  public  «»r  because  die  network  I*  attached  (o  other 
iictwoiks  wnb  mu  Seated  users  dim  du-  iinmiiumi  ei.-.natn  e  is  mssuiih-cI 
lo  he  l  m  h-ared  {l  S  III  thlsea.se  |<nnri--=0 

an  example  assume  a  guarded  liuildilijl  wil)i  a  local  area 
lie!  work  The  I. AN  lots  pro»s-sso|  .s  ;||  ( Ip  Secret  lev  el  alld  ollly  those 
individuals  with  Se  *ret  .iad  higher  i-leuranccs  are  able  to  use  die 
lermilials.  Ihe  |. AN  is  not  eonucited  to  ally  oilier  networks  o| 
conimunirai ions  lines  outside  tin*  building  Only  persons  with  at  leuMt 
a  ( ‘oiil'ldetil  ml  clearance  a-r  periiulti-d  into  die  building  without  all 
escort.  Ill  tills  case,  all  Rimn  of  *J  { correspond  ill}  In  the  unescorted 
( ‘oid’nh'nt ml  persotincl)  is  iiHcd  in  Pari  I  evahmtioas  .»|  this  system,  an 
IEiiim  of -I  ("»i  r«-.s|»o|idilig  to  Secret  J  Would  be  used 

Table  *J  now  goes  the  strength  of  mechanism  retjuiremenl  based 
"It  the  Risk  hides  rah  n!at«-d  as 
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Table  2  Table  j 

Minimum  Strength  of  Mechanism  Requirement  Pert  Q  Assurance  Rating 


Risk 

Strength  of 

0 

None 

1 

Minimum 

2 

Fair 

>2 

Good 

The  Part  II  Risk  Index  for  the  system  described  above  is  3  • 
2  =  1.  According  to  the  Table  2,  a  minimum  strength  mechanism 
would  suffice.  If  the  scenario  described  above  were  changed  to  include 
an  unprotected  communication  line  between  buildings  in  an  open  space, 
the  Rmrn  would  be  0.  The  new  Risk  Index  is  3-0  =  3,  and  a  good 
strength  of  mechanism  is  required. 

Assurance  Assurance  is  a  very  important  concept  in  the  TCSEC 
and  TNI.  This  section  discusses  the  need  for  assurance  and  the  ways 
in  which  it  may  be  achieved. 

One  salient  property  of  trusted  network  systems  is  the  reliance  on 
an  NTC'B.  In  addition  to  its  other  responsibilities,  the  NTCB  prevents 
unauthorized  modification  to  objects  within  the  network  system,  in 
particular,  the  NTCB  maintains  the  integrity  of  the  programs  which 
provide  security  services,  thus  ensuring  that  their  assurance  is 
continued.  The  NTCB  provides  an  execution  environment  tiiat  is 
extremely  valuable  in  enhancing  the  assurance  of  security  .vrviccs 
Discretionary  and  mandatory  access  controls  can  be  employed  to 
segregate  unrelated  services,  Thus,  service  implementation  that  is 
complex  and  error-prone  or  obtained  from  an  unevaluated  supplier  can 
lie  prevented  from  degrading  the  :u»uranee  of  other  services 
implemented  in  the  same  component.  Furthermore,  an  NTCB  ensures 
i  lint  the  basie  protection  of  llte  security  and  integrity  information 
entrusted  to  the  network  is  not  diluted  by  various  supporting  security 
services. 

The  relationship  of  the  Risk  Index  to  the  required  assurance  is 
expressed  in  Table  3. 

Table  H 

Minimum  Assurance  Requirements 


Risk 

Part  II 

Index 

Assurance  Rating 

0 

Norte 

1 

Minimum 

2 

Fair 

>2 

Good 

Assurance  oi  the  design  and  implementation  of  Part  Ii 
mechanisms  is  also  related  to  the  assurance  requirements  in  Part  i 
because  service  integrity  depends  on  protection  by  the  NTCB  Table  4 
expresses  this  dependency.  The  second  column  identifies  th  ■  minimum 
Part  I  evaluation  which  supports  the  Part  II  assurance  requiiement. 

The  reader  should  note  that  it  is  not  valid  to  attempt  to  join 
Tables  3  and  4  to  relate  the  Risk  Index  to  a  Part  I  rating  class  because 
Part  I  requirements,  as  expressed  in  Table  3,  include  functionality, 
strength  of  mechanism,  and  assurance,  while  Table  9  only  addresses 
assurance.  Furthermore,  recall  from  the  previous  section  that  the  Rtnm 
for  Part  II  may  be  different  from  that  of  Part  I  since  many  of  the  Part 
11  protections  are  oriented  towards  outsiders  rather  than  other  users. 


Part  11 

Assurance  Ratine 

Minimum  Part  I 
Evaluation 

Minimum 

Cl 

Pair 

C2 

Good 

B2 

Functionality  of  Specific  Security  Services 

This  section  provides  questions  about  each  of  the  security  services 
contained  in  Part  II  of  the  TNI.  It  devotes  a  series  of  questions  to  each 
security  service.  These  questions  are  designed  help  the  security 
manager  identify  the  functionality  required  for  each  security  service.  In 
considering  these  questions,  the  security  manager  may  wish  to 
substitute  a  weaker  noun  for  "requirement."  The  questions  should  be 
answered  in  sequence,  unless  the  answer  to  one  question  contains  an 
instruction  to  skip  ahead. 

Authentication 

1.  is  there  a  requirement  to  determine  what  individual,  process  or 
device  is  at  the  other  end  of  a  network  communication? 

if  no,  skip  to  Communications  Field  Integrity. 

2.  Can  you  identify  the  basis  for  this  requirement  in  a  policy,  concept 
of  operations,  or  similar  document? 

R  not,  you  should  confirm  and  document  the  validity  of  this 
requirement. 

3.  Do  you  have  a  requirement  to  identify  and  authenticate  the  specific 
hardware  device  at  the  distant  end-point  involved  in  the  network 
communication? 

If  yes,  then  you  have  a  functionality  requirement  for  authentication. 
This  functionality  may  be  implemented  ut  one  or  more  protocol 
layer.  For  example,  a  specific  control  character,  ENQ  (enquiry  or 
who-are-you)  may  be  used  to  immediately  return  a  stored  terminal 
identifier. 

4.  Do  you  have  a  requirement  to  identify  and  authenticate  the  location 
of  the  hardware  at  the  distant  end-point  or  in  any  intermediate 
system  involved  iti  the  network  communication? 

If  yes,  then  you  have  a  functionality  requirement  for  authentication 
at  protocol  layer  2,  the  Link  Layer  or  layer  3,  the  Network  Layer. 

•>.  Do  you  have  a  requirement  to  identify  and  authenticate  the  specific 
operating  system  or  control  program  at  the  distant  end-point  or  in 
any  intermediate  system  involved  in  the  network  communication? 
if  yes,  then  you  have  a  functionality  requirement  for  authentication 
at  protocol  layer  4,  the  Transit  Layer. 

6.  Do  you  have  a  requirement  to  identify  ami  authenticate  the  subject 
(process/domain  pair)  at  the  distant  end-point  involved  in  the 
network  communication'’ 

If  yes,  then  you  have  a  functionality  requirement  for  authentication 
at  protocol  layer  4  or  above. 

7  Do  you  have  a  requirement-  to  identify  and  authenticate  the 
application  or  user  at  the  distani  end-point  involved  in  the  network 
communication? 

If  yes,  then  you  have  a  functionality  requirement  for  authentication 
above  protocol  layer  7,  the  Applications  Layer.  The  Applications 
Layer  provides  an  interface  to  the  application.  Authentication 
information  may  pass  over  this  interface.  Authentication  of  a  user 
is  addressed  in  Part  I  of  the  TNI,  Application  process 
authentication  is  outside  the  scope  of  the  OSI  Security 
Architecture,  but  does  fall  within  the  scope  of  TNI  Part  II  Security 
Services. 
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Him*  you  chosen  to  use  some  mechanism  other  than  encryption  to 
provide  authentication?  If  so,  your  strength  of  mechanism  is  shown 
in  Table  2. 

If  your  authentication  mechanism  is  encryption  based,  see  the 
appropriate  encryption  authority  (e.g.,  NSA  for  the  DoD).  Even  if 
encryption  is  used  some  supporting  processes  may  need  to  satisfy 
the  strength  of  mechanism  shown  in  Table  2  (depending  on  the 
architecture}  Tor  example,  a  database  that  relates  encryption  keys 
to  specific  users  may  need  to  be  trusted 
Communications  Field  Integrity 

1.  Do  you  have  a  requirement  to  protect  communication  against 
unauthorized  modification? 

If  no,  skip  to  Non-repudiation. 

2.  Are  your  protection  requirements  the  same  for  all  parts  of  the 
information  communicated? 

If  no,  then  you  should  identify  the  separate  parts  and  answer  the 
rest  of  the  question*  in  this  section  separately  for  each  part.  Each 
part  is  known  as  si  field. 

There  are  two  major  fields:  protocol-infortir.it ion,  wherein  the 
network  is  infotmed  of  the  destination  of  the  information  ami  any 
special  services  required;  and  User-data.  Not  every  protoeol-dulu- 
unii  (PDl)  contains  user-data,  but  protocol- information  is 
necessary.  Each  of  these  fields  may  he  divided  into  additional 
fields:  depending  on  your  application,  protection  requirements  for 
fields  may  differ. 

3.  l>i>ynii  have  n  requirement  for  detecting  unauthorized  modification 
lu  pari  or  all  ul  a  I’Dl-? 

If  yes.  you  have  a  requirement  for  at  least  minimum  functionality 
3.  Do  you  have  a  requirement  for  detecting  any  of  the  following  forms 
of  message  stream  imidiTie-.il ion:  insertion,  deletion,  or  replay? 

If  yes.  you  have  a  requirement  for  at  least  fair  functionality.  In 
addition,  vour  fund  ion  alitv  must  be  incur  porn  ted  in  a  connection 
oriented  protocol. 

1.  1)<»  von  require  ihn*.  if  message  stream  modification  is  delected, 
recovery  (correction)  si -on Id  be  attempted? 

If  yes,  you  have  a  requirement  lor  good  func Humility.  In  addition, 
you  must  impleni#,iil  integrity  in  a  reliable  transport  (layer  1) 
mechanism. 

Non-repudiation 

1  Do  you  have  a  requirement  lo  be  able  to  prove  that  a  specific 
mi'.ssiige  transfer  actually  occurred? 

If  no.  skip  to  C  ’ontiiiiiity  of  Opera innis. 

2.  Do  you  have  a  rcquireiueut  for  proving  that  a  specific  message  was 
sent?  Specific  nn'.sxiHjr  means  that  the  identity  of  the  subject 
sending  the  message,  the  host  computer  and/or  mail  agent.,/ server, 
lime  and  dale,  and  eonlrnts  are  all  uniquely  and  unalterably 
identified. 

11  yes.  i hen  you  have  »  funeiioiialit-y  requirement  for  non- 

repudiation  with  proof  of  origin. 

3.  Do  you  have  n  requirement  for  proving  that  a  speeifie  message  was 
received’  >rnrifir  incMtign  means  that  the  identity  of  the  subject 
to  which  1  In-  message  was  delivered,  the  host  computer  and/or  mail 
agent/server,  tunc  and  date,  and  contents  are  all  uniquely  and 
unalterably  id*  n lifted. 

If  yes.  th. m  you  have  a  functionality  requirement  For  non¬ 

repudiation  with  proof  of  delivery 

Continuity  of  Operations 

I.  Do  you  have  a  requirement  to  assure  the  availability  of 
rum  mimic  at  ions  service  or  to  determine  when  a  denial-of-aervire 
(DOS)  condition  exists?  A  ilrni(it»nf-si:nure  condition  is  defined  to 
exist  whenever  thloughpiil  filMs  below  a  pre-established  threshold, 
■>r  when  access  \>>  :i  ren».ic  entity  is  unavailable,  or  when  resources 
;ire  not  available  lo  iwrs  on  an  equitable  basis. 

If  ll«».  skip  to  Protocol  Mused  DOS  Protection. 


2.  Do  you  have  a  requirement  to  detect  conditions  that,  would  degrade 
seme*  below  a  p-e-selceted  minimum  and  to  report  such 
degradation  to  the  network  operators? 

If  yes,  you  have  a  requirement  for  at  least  minimum  continuity  of 
operations  functionality. 

3.  Could  failure  of  the  system  to  operate  for  seve.al  minutes  lead  to 
personal  injury  or  large  financial  loss? 

If  yes,  you  have  a  requirement  for  at  least,  fair  continuity  of 
operations  functionality. 

4.  Do  you  have  a  requirement  for  service  resiliency  that  would 
continue  - perhaps  in  a  degraded  or  prioritized  mode  in  the  event 
of  equi|-ni'-nt  failure  atul/or  unauthorized  actions? 

If  yes.  you  have  a  requirement  Tor  at  least  fair  continuity  of 
operations  func iHiality. 

5.  Could  failure  of  your  system  to  operate  for  severnl  minutes  lead  to 
loss  of  life? 

If  yes.  you  have  a  requirement  for  good  continuity  of  operations 
functionality. 

t>.  Do  you  have  a  requirement  for  automatic  adaptation  upon 
detection  of  a  deniul-ol-service  condition? 

If  yes,  you  have  a  requirement  For  good  continuity  of  operations 
functionality. 

Protocol  Based  DOS  Protection 

1.  Do  you  have  a  requirement  to  probe  or  test  the  availability  of 
service? 

If  no,  skip  to  Network  Management. 

2.  The  TNI  suggests  t  hat  the  number  of  protocol  based  median  isms 
could  be  used  as  the  basis  for  determining  the  required 
functionality.  Do  you  have  an  alternative  basis  for  establish 
functionality  requirements? 

If  yes.  von  should  employ  this  alternative  basis  and  skip  lo  Network 
Management 

3.  Do  you  have  a  requirement  lo  detect  a  Denial  of  Service  condition 
width  cannot  l>c  met  by  the  protocols  used  as  pari  of  uotiual 
coiniminit  alioiis? 

Kor  example,  you  may  require  priority  schemes  (hat  some  protocols 
to  not  provide. 

If  noi.  you  do  not  have  a  functional  requirement-  for  protocol  based 
DOS  prelection  and  should  skip  to  Nt  .work  Management 
-I.  The  TNI  suggests  the  following  protocol  based  mechanisms: 

n  Measure  the  i  fa  i  is  mission  rate  between  peer  entities  under 
conditions  of  input  queuing,  and  compare  the  measured 
1 1 iiiisinissii mi  late  with  .i  rule  previously  identified  as  the 
luiiiiliitiiti  acceptable; 

Q  Employ  a  request -respond*  polling  mechanism,  such  as  “nre- 
yoii-t  here”  and  “herc-l-am  1  messages,  to  verify  that  an  open 
path  exists  between  peer  entities. 

Have  you  identified  any  additional  mechanisms  required  for  vour 
svxteiii? 

if  so.  include  these  additional  mechanisms  in  your  list  of  required 
mechanisms. 

■r).  Mused  the  previous  question,  how  many  protocol  based  mecliaiusms 
do  you  require?  (Continue  with  t-he  next  question  ) 
l).  Do  you  require  tint  any  protocol  based  mechanism  be  designed  to 
not  aggravate  a  Denial  of  Service  condition? 

for  example,  request- response  and  poling  mechanisms  have  been 
known  to  crash  or  overload  packet  switching  networks. 

If  so.  add  one  (1)  to  your  sum  of  protocol  based  mechanisms. 

The  relationship  of  number  of  mechanisms  and  functionality 
requirement,  is  shown  in  Table  r>. 
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Network  Management 

1.  Do  you  have  a  requirement  for  (at  least)  detecting  a  denial  of 
service  condition  that  affects  more  than  a  single  instance  of 
communication,  or  attempted  communication? 

If  no,  skip  to  Data  Confidentiality. 

If  yes,  you  have  a  functional  requirement  fer  network  management 
denial  of  service  protection. 

Table  ,7 

Protocol  Baaed  DOS  Functionality  Mechanism  Requirements 


Number  of 

Functionality 

Mechanisms  Rating 

Requirement 

0 

None 

1 

Minimum 

2-3 

Kail 

'■3 

Clood 

Data  Confidentiality 

1.  Do  you  have  a  requirement  to  protect  any  part  of  transmitted  data 
from  disclosure  to  unauthorized  persons:' 

If  no.  skip  to  Traffic  Flow  Confidentiality 

2.  Is  your  requirement  for  confidentiality  limited  to  selected  field  of 
user-data  within  a  PDU? 

If  no,  then  you  require  confidentiality  lor  the  entire  data  portion  of 
each  PDIF  Continue  with  Traffic  Flow  Confidentiality. 

3.  Is  there  a  reason  to  encrypt  only  selected  fields  (e  g.,  cost  savings, 
legal  requirements)? 

If  yes,  you  require  selected  field  confidentiality.  If  no.  you  require 
full  confidentiality  on  the  data  portion  of  each  l’lHF 
Traffic  Flow  Confidentiality 

I.  Do  you  have  a  requirement  to  prevent  analysis  of  message  length, 
frequency,  and  protocol  components  (such  as  addresses)  to  prevent 
information  disclosure  through  inferenee  (traffic  analysis)? 
if  no.  skip  to  Selective  Routing. 

If  yes,  you  have  a  functional  requirement  for  traffic  flow 
confidentiality 

Selective  Routing 

I.  Do  you  have  a  requirement  to  choose  or  avoid  specific  networks, 
links,  relays,  or  other  components  for  any  reason  at  any  time.’ 

If  yes.  you  have  a  functional  requirement  lor  selective  routing 

Conclusions 

This  paper  has  discussed  ongoing  work  lining  done  lor  the 
National  Computer  Security  Center  l»y  MITKK.  Plans  call  for  a 
distribution  ol  a  drall-  version  to  a  lew  dozen  reviewers  during  the 
Summer  of  1 DKH  followed  by  revision  and  distribution  of  tin-  document 
to  tin  various  services  and  agencies  before  the  i-tid  of  tin  calendar 
year  Depending  on  the  nai  tire  of  comments,  a  filial  version  may  be 
available  in  the  Spring  of  I  US!) 

The  prefered  approach  for  accrediting  systems  is  to  evaluate  a 
network  system  that  includes  end  systems  and  intermediate  systems, 
if-,  the  full  seven  layers  OS|  phis  the  applications.  The  evaluation 
process  of  a  single  trusted  system  under  Part  I  of  the  TNI  is  veri¬ 
similar  to  that  of  a  stand  done  system  atm  the  environmental  guidlines 
are  similar  as  well  One  important  difference  is  t  ii.it  It  nun  may  lie 
bused  on  users  or  operations  personnel.  The  presence  of  E'*  requires 
that  the  Risk  Index  for  maximum  clnssifleatioii  and  minimum  rienrnnee 
lie  compared  to  the  Risk  Index  for  the  encryption  bypass;  the  larger  of 
tlie  two  is  used  lor  environmental  rulridaiioiis. 


Although  a  single- 1  rusted-syst  cm  approach  is  prefered,  it  is 
recognized  that,  at  least,  for  the  near  t.ernt,  existing  accredited  AIS  will 
lie  part  of  many  networks.  Since  it  is  unlikely  that  these  systems  can 
lie  part  of  a  single  trusted  system,  a. set  of  more-lenient  interconnection 
rules  has  been  established.  These  rules  require  the  exchange  or  MOAs 
between  cognizant  accrediting  authorities  who  are  willing  to  accept  the 
risk  of  attaching  their  systems  to  each  other.  In  the  case  of  a  common 
user  network,  a  network  accreditor  is  under  a  fiduciary  responsibility 
to  protect  the  other  AIS  that  have  been  attached  previously.  Any  need 
to  attach  an  AIS  that  does  not  satisfy  the  network  attachment 
standards  must  lie  weighed  carefully  against  the  additional  security 
threat  which  may  be  propagated  toother  AIS. 

Part  II  of  the  TNI  is  more  qualitative  than  Part  I.  Its 
requirements  do  not  have  the  strong  mathematical  bases  behind  the 
Part  I  criteria.  Part  11  applies  to  systems  evaluated  as  a  single  trusted 
system  ns  well  as  to  systems  of  interconnected  AIS.  Part  II  uses  the 
Risk  Index  as  does  part  I,  however  the  Part  I  and  II  indexes  may  differ 
lor  the  same  system  bemuse  in  some  cases  the  Rinta  is  different.  To  a 
large  extent,  Part  I  criteria  protect  users  from  other  system  users, 
while  Part  II  requirements  protect  users  from  outsiders.  Providing 
environmental  guidance  was  difficult.  Quite  frankly,  the  guidance  was 
based  on  measures  that,  seemed  right  to  the  authors  It  is  the  authors’ 
hope  that  readers  will  consider  the  measures  iu  terms  of  their  own 
systems  and  they  will  provide  the  authors  with  feedback  about  whether 
the  measures  serin  right  to  (hem  in  a  sort  of  informal  Delphi 
methodology. 
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ABSTRACT 

Security  in  the  standards  arena  is  emerging  ns  a  pressing  topic 
for  discussion  and  for  imminent  standardization.  The 
International  Standards  Organization/Open  Systems 
Interconnection  (1SO/OSI)  protocols  are  being  implemented 
and  accepted  as  the  future  standard  for  till  communications 
networks.  The  need  to  provide  security  for  each  participant  in 
an  open  system  has  emerged  as  one  of  the  important  riddles 
which  must  he  solved  before  OSI  will  be  used  whole-heartedly. 

This  paper  summarizes  the  security  activities,  as  of  May  HISS, 
of  the  various  standards  bodies  which  are  developing  security- 
related  standards  within  the  contest  of  the  ISO/OSI  reference 
model,  In  order  to  provide  a  coherent  description  of  the 
various  activities,  the  structure  of  the  standards  organizations 
is  shown,  the  interactions  among  the  organizations  are 
explored,  and  the  work  progressing  within  each  organization  is 
summarized.  In  addition  to  a  description  of  the  security  work 
progressing  in  the  official  standards  organizations,  an  overview 
of  programs  within  the  BoD  which  are  promoting  the 
standardization  of  ISO/OSI  security  is  provided.  Finally, 
conclusions  are  drawn  about  the  progress  of  standardization  of 
security. 


1.0  INTRODUCTION 

There  are  several  international  and  national  United  Stales 
standards  bodies  as  well  as  United  States  government 
organizations  which  are  working  to  develop  security  standards 
for  the  OSI  Basic  Reference  Model  jl|.  All  of  the  organizations 
exchange  information  about,  their  work  through  specific,  well- 
dclined  channels.  Figure  I  shows  the  various  organizution  and 
their  official  working  relationships. 

I  he  international  standards  organizations  which  are  working 
on  the  security  aspects  of  open  systems  are  the  International 
Standards  Organization  (ISO),  the  European  Computer 
Manufacturer’s  Association  (ECMA),  and  the  International 
Telegraph  and  Telephone  Consultative  Committee  (CC'ITT). 
ISO  hits  been  a  major  contributor  in  the  area  of  security  with 
standards  lor  security  architecture  and  for  security 
management.  ECMA  and  CC1TT  have  parallel  committees  to 
those  in  ISO;  they  contribute  to  the  development  of  ISO/OSI 
security  standards  via  liaisons. 

The  United  States’  national  organizations  which  lire  associated 
vvith  the  ISO  security  work  are  the  American  National 
Standards  Institute  (ANSI),  the  Manufacturing  Automation 
I’rotocol/T echn ical  Office  Protocol  (MAI’/TOI*),  and  the 
National  Bureau  of  Standards  (NIIS)  Implementor’s  Workshop. 

ANSI  is  the  formal  U.S.  representative  to  ISO.  Within  ANSI, 
there  are  parallel  committees  to  those  in  ISO.  Each  committee 
is  the  formal  U.S.  representative  to  the  corresponding  ISO 
committee. 

The  Manufacturing  Automation  I’rotocol/Tcclinicnl  Office 
Protocol  (MAP/'I OP]  hies  user  organizations  world-wide  and 
lues  the  status  of  official  contributor  to  the  ISO  committees 


MAP,  representing  a  consortium  of  factory  automation  users 
headed  by  General  Motors,  and  TOP,  representing  the  office 
automation  community  headed  by  Boeing,  are  developing 
specifications  of  specific  subsets  of  ISO  standards.  In  areas 
where  ISO  standards  arc  not  yet-  fully  mature,  the 
corresponding  MAP/TOP  committees  are  trying  to  accelerate 
the  process  of  defining  OSI  standards  by  developing 
MAP/TOP  solutions  which  are  being  fed  into  the  appropriate 
ANSI  committee.  In  addition,  MAP/TOP  is  drawing  on  the 
standards  being  developed  at  the  NBS  Implementor’s 
Workshop  and  using  the  Implementor's  Agreements. 

The  NBS  Implementor's  Workshop  has  much  the  sumc  goals  as 
well  les  the  same  participants  ns  MAI’/TOI'.  The  goals  of  the 
workshop  are  to  promote  multi-vendor  interoperability  quickly 
by  developing  Implementor’s  Agreements  for  a  specified  subset 
of  international  security  standards'  options.  These  agreements 
will  form  the  basis  for  security  capabilities  within  the 
Government  OSI  Profile  (tlOSIP),  which  are  the  specific 


Figure  1.  International  and  U.S.  Organizations  Working  on 
ISO/OSI  Security 
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subsets  of  international  standard  protocols  to  be  procured  by 
the  Federal  government. 

GOSIP  is  being  developed  by  the  Defense  Communications 
Agency  (DCA)  fo;  use  in  the  Internet.  The  other  United 
States  government  agency  which  is  developing  security 
standards  based  on  the  OS1  model  is  the  National  Security 
Agency  (NSA)  Their  program  is  the  Secure  Data  Network 
System  (SDNS)  program. 

Doth  the  international  and  United  States  national  standards 
organizations  are  composed  of  committees  which  are  devoted 
to  particular  topics.  Within  ISO.  the  Technical  Committees 
(TCs)  which  have  significant  security  activities  are  Information 
Technology  Standards  and  Banking.  Recently,  the 
International  Electronical  Commission  (IEC)  has  formed  a 
specific  liaison  with  the  ISO  TC97  committee  (Information 
Processing)  to  sponsor  the  Joint  Technical  Committee  I 
(JIC1).  The  I  EC  is  an  adjunct  of  ISO  which  addresses  the 
standardization  for  electrical  and  electronic  engineering 
equipment. 

The  five  Subcommittees  (SCs)  within  these  TCs  which  have 
active  security  subgroups  arc  bower  Layers,  Data 
Encipherment,  Architecture,  Information  Interchange,  and 
Electronic  Funds  Transfer,  Figure  2  lists  these  groups  showing 


figure  2.  ISO  Committees  Working  on  ISO/OSl  Security 

which  subcommittees  belong  to  each  technical  committee.  The 
Working  Croups  (WCs)  within  these  SCs  which  specifically  are 
addressing  security  issues  in  OSI  nrc  shown  in  Figure  3. 
Within  ANSI,  there  are  several  groups  which  contribute  to  the 
ISO  Working  Groups  addressing  security.  Figure  -I  lists  those 
ANSI  groups,  showing  the  corresponding  ISO  Working  Group. 

The  list  ol  groups  working  on  OSI  security  issues  is  extensive 
However,  the  groups  do  make  attempts  to  work  together  so 
that  work  is  not  duplicated  unless  such  duplication  is 
necessary.  Thus  among  the  various  groups,  there  are  many 
liaison  efforts  which  are  progressing  security  standards.  Figure 
!i  and  Figure  (i  show  the  major,  current  liaison  activities  of 
each  group  as  of  May  1988. 

The  following  sections  summarize  the  particular  security 
activities  of  each  working  group  ill  the  context  of  their 
international  or  national  organization,  and  give  a  brief 
summary  of  any  standards  which  the  group  is  developing 
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Figure  S.  1SQ/JTC1  Liaisons 


2.0  INTERNATIONAL  STANDARDS 
ORGANIZATION  (ISO) 

The  goal  of  the  Open  Systems  Interconnection  activity  of  the 
International  Standards  Organization  (ISO)  is  to  promote 
standardization  of  those  functions  needed  to  support 
communication  between  open  systems  ISO  is  a  voluntary 
organization  whose  voting  rights  are  given  to  the  national 

standards  bodies  of  participating  countries.  For  example, 
ANSI  is  the  United  States  representative  to  ISO. 


2.1  Information  Technology  Standards  (JTC1) 

The  purpose  of  JTCl  is  standardization,  including 
terminology,  in  the  field  of  information  processing  systems 
including,  but  not  limhed  to,  personal  computers  and  office 
equipment.  Figure  7  shows  the  organization  of  JTCl  security 
activities.  The  following  sections  describe  the  activities  of  each 
Working  Group  within  each  subcommittee  (SC)  as  shown  in 
Figure  7. 

2.1.1  Telecommunications  and  Information 
Exchange  Between  Systems  (SC6) 

2. 1.1.1  Transport,  Layer  4  Security  (WG4) 

The  working  group  is  developing  protocols  which  incorporate 
data  protection  services  at  the  transport  layer.  The  model  for 
this  protection  of  transport  data  will  be  taken  from  the  work 
being  done  in  SC20  or  SC21.  The  members  of  SC6  do  not 
intend  to  develop  the  model  in  their  group. 

2.1.2  Text  and  Office  Systems  (SC18) 

The  SC18  group  works  with  ECMA  TC32  and  with  CCITT  on 
the  Message  Handling  System  (MIIS)  standards.  The  security 
portions  of  these  standards  present  a  security  policy  |2|,  a 
security  model  [Hi,  a  security  service  definition  for  the  message 
transfer  service  |.||,  and  a  security  service  definition  for  the 
message  store  [6], 


2. 1.2.1  Standards  for  Message  Handling 
Systems 

The  Message  Handling  System  standards  are  a  set  of  standards 
which  define  tho  systems  and  services  which  allow  users  to 
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exchange  messages  using  a  store  anil  forward  architecture. 
The  basic  functional  entities  of  the  Message  Handling  System 
arc  the  User  Agents  (UAs),  the  Message  Transfer  System 
(MTS)  which  is  composed  of  Message  Transfer  Agents  (MTAs) 
and  tlie  Message  Store  (MS).  The  User  Agents  are  application 
processes  which  submit  and  receive  messages  on  behalf  of  the 
user.  The  Message  Transfer  Agents  transfer  messages  and 
deliver  messages  to  the  destination  specified  by  the  user  via  the 
User  Agents.  The  Message  Store,  which  is  an  optional 
function,  can  by  used  to  store  and  to  permit  retrieval  of 
messages  between  the  User  Agent  and  the  Message  Transfer 
Systems.  The  security  model  for  the  system  defines  services 
which  would  allow  these  entities  or  components  to  be 
protected. 

The  security  model  lias  two  views:  Secure  Access  Management 
and  Administration  and  Secure  Messaging.  Secure  Access 
Management  and  Administration  addresses  "the  establishment 
or  an  authenticated  association  between  adjacent  components 
and  the  setting  up  of  security  parameters  for  that  association." 
Secure  Messaging  "covers  the  application  or  security  features  to 
protect  messages  in  the  Message  Handling  System  in 
accordance  with  a  defined  security  policy  |2|." 

The  services  provided  for  Message  Handling  security  are  based 
on  ISO  7-t 5)8/  Part.  2  (l|.  These  classes  of  services  are:  message 
origin  authentication,  report  origin  authentication,  probe  origin 
authentication,  proof  of  delivery,  proof  of  submission,  secure 
access  management,  content  integrity,  content  confidentiality. 

message  flow  confidentiality,  message  sequence  integrity,  non¬ 
repudiation  of  origin,  non-repudiation  of  delivery,  and  non¬ 
repudiation  of  submission. 

The  services  within  each  class  arc  defined  in  detail  in  X.-I02  [3] 
and  are  listed  in  Figure  3.  The  security  parameters  for  the 
services  provided  by  the  Message  Transfer  system  and  the 
Message  Store  are  defined  in  X.-l 1 1  [d|  and  X.4I3  (51 
respectively.  The  classes  of  threats  which  these  services 
address  are  access  threats,  inter-message  threats,  intra-message 
threats,  and  data  store  threats, 

The  treatment  of  security  in  the  Message  Handling  System  is 
one  of  the  most  thorough  definitions  and  set  of  services  in  any 
of  the  ISO  standards. 

2.1.3  Information  Processing  Systems  Data 
Cryptographic  Techniques  (SC20) 

The  security  activities  in  lSO/JTt'l/SC20  ure  taking  place  in 
WGI,  WCI'i,  and  W(!3  in  the  areas  of  protocol  development 
and  algorithm  registration.  The  ISO  executive  committee  has 
voted  that  algorithms  cannot  be  standardized  by  ISO 
committees,  thus  the  work  in  S('20  may  be  slowing  down. 
Although  there  is  work  progressing  in  the  areas  of  Secret  Key 
Algorithms  and  Applications  (WOl)  and  in  Public  Key 
Cryptosystems  and  Mode  of  Use  (W(12),  these  activities  are 
similar  to  those  of  iSO/TCIi8  in  the  banking  community. 

2. 1.3.1  Use  of  Encipherment  Techniques  in 
Communications  Architectures  (WG3) 

The  security  activities  of  WCi3  are  the  definition  of  a 
procedure  for  registering  algorithms  and  the  development  of 
standards  for  cryptographic  techniques  in  connection-oriented 

protocols  and  for  public  key  encryption.  The  following 
sections  summarize  each  of  these  efforts  and  poinL  out  areas 
where  work  is  still  to  be  done  or  perhaps  redone. 

2. 1.3. 1.1  ISO  Register  of  Encipherment 
Algorithms.  A  set  of  procedures  is  being  defined  for 
registering  algorithms.  The  following  list  is  a  first  draft 
definition  of  what  comprises  the  registration  or  an  algorithm. 

I.  Unitpie  Identification  (assigned  by  SC20) 


Origin  Authentication 

Message  Origin  Authentication 
Probe  Origin  Authentication 
Report  Origin  Authentication 
Proof  of  Submission 
Proof  of  Delivery 

Secure  Access  Management 
Peer  Entity  Authentication 
Security  Context 

Data  Confidentiality 

Connection  Confidentiality 
Content  confidentiality 
Message  Flow  Confidentiality 

Data  Integrity  services 

Connection  Integrity 
Content  Integrity 
Message  Sequence  Integrity 

Non-Repudiation 

Non-repudiation  of  Origin 
Non-repudiation  of  Submission 
Non-repudlatlon  of  Dellvory 
Message  Security  Labelling 

Security  Management  Services 

Change  credentials 
Register 


Figure  8.  Message  Handling  Security  Set-vires 


2.  Proper  Name 

3.  Range  of  Application  (services  provided) 

■I.  Modes  of  Operation 

5.  Cryptographic  Interface 

6.  Test  of  Words 

7.  Patent  Information 

8.  References  to  Standards 

9.  Name  of  Sponsor 

Information  describing  the  algorithm  and  the  strength  ol 
algorithm  is  not  required  for  registration. 

The  work  to  be  done  in  this  area  is  to  define  completely  the  set 
of  procedures  as  well  its  to  define  the  terminology,  such  ns 
"Encipher!!, ett  l  A  Igori thm 

2.1.3. 1.2  Standard  for  Data  Cryptographic 
Techniques.  The  first  working  draft  of  the  standard  lor 
data  cryptographic  techniques  was  developed  ns  of  September 
1988  and  as  the  introduction  states,  "the  text  is  provisional 
and  subjert  to  radical  change  |0j .”  This  standard  will  apply  to 
the  connection-oriented  protocol  specification  DIS  8073  and 
will  define  all  elements  of  cryptographic  bused  data  protection 
mechanisms  except  for  the’  cryptographic  algorithms.  The 
work  being  done  in  the  group  is  evolving  toward  a  transport  to 
network  interface  where  encryption  is  a  sublayer  between  the 
transport  and  network  layers. 
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The  intent  of  the  standard  as  it  is  currently  drafted  is  to 
provide  mechanisms  to  support  the  securitj  services  defined  in 
DP-7498/2.  These  services  include  peer-entity  authentication, 
connection  confidentiality,  and  connection  integrity  with  and 
without  recovery  all  at  layer  4. 

The  elements  of  procedure  or  facilities  which  provide  the 
mechanisms  are  listed  below. 

Connection  Establishment 
Peer-Entity  Authentication 

Data  Encipherment 
Integrity 

Unique  Sequence  Numbers 


The  classes  of  end-to-end  transport  protocol  layer  services  to 
which  the  standard  applies  are  1,  2,  3,  4.  Class  0  is  not 
included  because  it  is  designed  for  minimal  functionality  and 
the  required  cryptographic  parameters  cannot  be 
accommodated  in  the  variable  header.  The  following  lists  the 
types  of  cryptographic  protection  for  each  transport  protocol 
class. 

a.  Class  1:  Basic  Error  Recovery  Class 

Unilateral  Peer-Entity  Authentication 
Confidentiality  of  User  Data 

b.  Class  2:  Multiplexing  Class 

Mutual  Peer-Entity  Authentication 
Confidentiality  of  User  Data 
Manipulation  Detection  for  all 
types  of  Transport  Protocol  Data  Units 
Replay,  insertion,  and  deletion  detection 
for  normal  data  stream 

c.  Class  3:  Error  Recovery  and  Multiplexing  Class 

Mutual  Peer-Entity  Authentication 
Confidentiality  of  User  Data 
Manipulation  Detection  for  all  types 
of  Transport  Protocol  Data  Units 
Replay,  insertion  and  deletion  detection 
for  all  user  data 

d.  Class  4  Error  Detection  and  Recovery  Class 

Same  services  as  for  Class  3 
Recovery  from  detected  integrity  errors 
is  provided  using  median  isms  from  class 
4  checksum  failures 

The  data  cryptographic  techniques  to  he  defined  in  this 
standard  are  for  end-to-end  protection  of  the  data.  Although 
no  algorithms  are  specified,  only  certain  algorithms  ure  suitable 
for  use  with  these  techniques  pl/'st  relevant  to  protection  on 
an  individual  end-to-eiul  connection  basis).  In  addition,  the 
techniques  defined  arc  only  as  secure  as  the  security  inherent  in 
the  management  of  the  cryptographic  keys. 

2. 1.3. 1.3  Standard  for  Public  Key  Encryption. 

The  standard  Tor  public  key  encryption  is  DEA  2  which 
specifies  the  algorithm  to  be  used  for  public  key  encryption 
protocols  |7j. 


2.1.4  Information  Retrieval,  Transfer,  and 
Management  for  OSI  (SC21) 

The  security  activities  in  SC21  are  being  addressed  in  the 
working  groups  WCI,  WC4,  and  WCli  in  the  areas  of  security 


architecture,  security  management,  directory  security,  and 
security  in  the  upper  layer  protocols  such  ns  presentation  layer 
protocols. 

There  is  a  proposal  for  new  work  to  develop  an  ISO 
Authentication  Framework.  Four  areas  would  be  investigated 
for  this  Meta-Architecture  definition:  Authentication  (WCIB), 
Access  Control  (WGl),  Security  Audit  (WG4),  and  Non- 
Repudiation  (WGl)  with  WGG  trucking  the  efforts  for 
consistency.  WC6  has  done  some  preliminary  work  in  this 
area  which  led  to  the  decision  that  there  is  a  need  for  a 
framework  in  this  area. 

The  current  efforts  in  security  standards  are  listed  in  the 
following  sections. 

2. 1.4.1  OSI  Architecture  (WGl) 

WGl  addresses  the  architecture  inspects  of  OSI.  Their  present 
effort  is  to  develop  an  OSI  security  architecture. 

2. 1.4. 1.1  OSI  Security  Architecture  Standard. 

The  standard  for  the  OSI  security  architecture  |8]  is  intended 
to  extend  the  field  of  application  of  ISO  7408,  the  Basic 
Reference  Model  for  Open  Systems  Interconnection,  to  cover 
secure  communications  between  open  systems.  The  standard 
has  progressed  to  the  level  a  Draft  International  Standard,  DIS 
7408-2,  as  of  May  1987.  this  document  is  being  revised  to 
progress  to  full  International  Standard  (IS)  status  in  1988. 

The  security  architecture  for  the  Reference  Model  is  defined  in 
terms  of  the  security  services  and  the  related  mechanisms 
which  can  be  provided  within  the  Reference  Model  framework. 
The  definition  and  placement  of  these  services  and  mechanisms 
form  the  core  of  the  document,  in  addition,  the  security 
architecture  standard  defines  the  architecture  for  security 
management  us  well  as  providing  a  tutorial  on  security,  n 
justification  of  security  service  placement  in  particular  layers, 
and  a  guide  for  placement  of  encipherment  ill  applications. 
The  security  architecture  and  the  security  management 
architecture  ure  discussed  here. 

The  security  architecture  supports  the  following  categories  of 
service. 

Authentication 
Access  Con  trol 
Data  Confidentiality 
Data  Integrity 
Non-Repudiation 

The  allocation  of  these  categories  of  service  to  each  lave"  is 
shown  in  Figure  9. 

Within  each  ol  these  categories,  specific  services  are  defined. 
Much  of  the  differentiation  between  services  is  to  accommodate 
connection-oriented  versus  connectionless  service  provided  by 
an  underlying  layer.  These  services  are  listed,  hut  nut 
described  in  Figure  10. 

The  types  of  mechanisms  which  can  lie  invoked  by  the  security 
services  arc: 

Encipherment 
Digital  Signature 
Access  Control 
Data  integrity 
Authentication  Exchange 
Traffic  Padding 
Routing  Control 
Notarization 

The  mapping  of  the  mechanisms  to  the  categories  of  services 
which  arc  allowed  to  invoke  each  mechanism  is  shown  in 
Figure  11. 
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Layer  7 

Application 

jthantlcatlon,  Aocaii  Control, 

Jata  ContkJentlallty,  Data  Integrity, 
Non-repudlatlon 

Layer  6 
Presentation 

Data  Confldantiallty 

Layer  5 

Session 

Layer  4 

Transport 

Authentication,  Aeetai  Control, 
Data  Conlldantl-iiity,  Data  Integrity 

Layer  3 

Network 

Authantlcation,  Aocaaa  Control, 

Data  Confidentiality,  Oata  Intaglrty 

Layer  2 

Data  Link 

Data  Confidentiality 

Layer  1 

Physical 

Data  Confldantiallty 

Figure  9.  Allocation  of  Categories  of  Services  to  Layers 


Authentication 

Peer  entity  authentication 
Data  origin  authentication 

Access  Control 

Data  Confidentiality 

Connection  confidentiality 
Connectionless  confidentiality 
selective  field  confidentiality 
traffic  flow  confidentiality 

Data  Integrity 

connection  Integrity  with  recovery 
connection  Integrity  without  recovery 
selective  field  connection  integrity 
connectionless  Integrity 
selective  field  connectionless  integrity 

Non-repudiation 

Non-repudlatlon  with  proof  of  origin 
Non-repudlatlon  with  prood  of  delivery 


Figure  10.  List  of  Specific  Security  Services 


There  are  some  additional  mechanisms  which  do  not  provide 
any  particular  service  at  a  given  layer,  but  which  are  defined 
as  "pervasive."  These  pervasive  security  mechanisms  which 
appear  to  apply  to,  or  would  be  used  by,  services  provided  by 
security  management  are: 

Trusted  Functionality 
Event  Detection 
Security  Audit  Trail 
Security  Recovery 

The  basic  framework  for  Security  Management  is  included  in 
the  standard  to  guide  the  development  of  subsequent  more 
specific  standards  on  managing  security  [9).  Security 
management  is  defined  as  the  management  aspects  of  OS1 
Security  that  are  concerned  with  those  operations  which  arc 
outside  normal  instances  of  communication,  but  which  are 
needed  to  support  and  control  the  security  aspects  of  those 
communications. 

There  are  four  categories  of  OSI  security  management  activities 
which  are  defined. 

1.  System  Security  Management 

2.  Security  Service  Management 

3.  Security  Mechanism  Management 

4.  Security  of  OSI  Management 


System  security  management  is  concerned  with  the 
management  of  the  security  aspects  of  the  overall  OSI 
environment  such  as  security  policy  or  event  handling.  This 
type  of  management  controls  the  pervasive  mechanisms  which 
apply  to  all  layers,  not  a  particular  layer. 

Security  service  management  and  security  mechanism 
management  are  concerned  with  the  management  of  particular 
services  and  mechanisms  respectively.  The  management  of 
services  and  mechanisms  also  applies  to  the  circumstances 
under  which  a  service  is  allowed  to  invoke  a  mechanism. 

Security  of  OSI  management  protects  all  OSI  management 
functions  and  the  communication  of  OSI  management 
information.  This  type  of  management  may  be  the 
embodiment  of  Trusted  Functionality  and  can  be  defined  as 
the  environment 
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Although  the  Security  Architecture  standa,d  is  declared  to  be 
ready  to  progress  to  the  status  of  a  full  international  stan  .iard, 
there  is  some  work  which  would  make  the  standard  moru 
useable.  Currently,  the  security  architecture  is  described  in 
terms  of  security  services,  mechanisms  those  services  can  use, 
and  the  layers  in  which  the  services  may  be  available.  There  is 
no  attempt  to  describe  which  combinations  of  services  provide 
a  particular  level  of  security.  For  example,  if  reliable 
authentication  is  a  goal  of  the  system,  then  not  only  is  the 
layer  7  service  of  peer  authentication  desirable,  but  the  layer  -4 
service  of  connection  confidentiality  is  useful  to  assure  that  no 
one  has  unauthorized  access  to  the  authentication  information 
as  it  is  transferred  across  the  network. 

Thus  there  is  a  need  for  an  appendix  or  an  accompanying 
guideline  to  provide  some  recommendation  of  how  to  combine 
security  services  within  layers  and  at  different  layers  to  achieve 
secure  communication  among  open  systems. 

2. 1.4.2  OSI  Management  (WG4) 

The  two  security  efforts  within  WG4  are  standards  for  security 
management  services  and  for  security  in  the  directory  services. 

2. 1.4.2. 1  Standard  for  Security  Management 
Services.  The  Security  Management  Standard  (!)]  defines  the 
specific  services  required  to  manage  and  to  control  OSI 
security.  Currently,  a  working  draft  of  the  eventual  standard 
exists  and  is  being  developed  within  the  Security  Management 
ad  hoc  group.  It  is  expected  to  progress  to  a  Draft  Proposal 
(DP)  in  1988.  The  security  services  arc  being  defined  so  that 
they  can  use  the  Common  Management  Information  Protocol 
(CMIP)  [10]  for  information  exchange. 

The  basic  definitions  and  the  architectural  concepts  used  in  the 
standard  are  based  on  the  Security  Architecture  Standard  |8|. 
The  way  the  service  definitions  are  structured  is  along  the 
categories  of  management  activities  defined  in  the  Security 
Architecture  Standard  as 

1.  System  Security  Management 
'2.  Security  Service  Management 
8.  Security  Mechanisms  Management 
■1.  Security  of  OSI  Management 

For  the  activities  of  System  Security  Management  and  Security 
Mechanism  Management,  the  following  aspects  are  defined:  a) 
the  facilities  used  to  manage  those  activities,  b)  the  functional 
units  (general  service  capabilities),  c)  the  primitives  and 

parameters  required  by  the  service.  The  current  list  of  specific- 
activities  which  the  group  is  investigating  is  listed  below. 

Event  Handling  management 
Security  audit  management 
Security  recovery  management 
Key  management 
Encipherment  management 
Access  control  management 
Data  integrity  management 
Authentication  management 
Traffic  padding  management 
Routing  control  management 
Notarization  management 
Digital  signature  management 

The  activities  of  Event  Handling  Management  and  the  Security 
Audit  Management  have  very  similar  definitions.  Either  the 
activities  will  be  combined  or  Event  Management  may  be  for 
the  control  and  reporting  of  events  and  Security  Audit  may  be 
for  the  logging  of  events  and  the  controlling  of  groups  of 
related  event  reports. 

Currently,  the  Management  Information  Service  Definition  for 
security  only  addresses  the  management  of  system  security  and 
security  mechanisms.  The  omission  of  Security  Service 


Management  needs  to  be  discussed  in  the  grout).  The  omission 
of  Security  of  OSI  Management  is  legitimate  as  this  type  or 
management  includes  Trusted  Functionality  which  will  be 
specific  to  each  system.  Other  items  to  be  included  in  the 
service  definition,  but  on  which  work  has  not  been  completed 
are:  a)  model  for  security  management;  b)  conformance 
.equipments;  and  c)  annexes  which  provide  background  on  the 
concepts  and  requirements  of  security  management. 

2.1.4.2.2  Standard  for  Directory  Security 
Services.  The  Directory  is  "a  collection  of  open  systems 
which  cooperate  to  hold  a  logical  database  of  information 
about  a  set  of  objects  ir.  the  real  world  (ll|.“  These  objects  arc 
application  entities,  people,  terminals  and  distribution  lists. 
The  services  offered  by  the  Directory  are  service  qualification, 
directory  interrogation,  directory  modification,  and  error 
messages. 

The  service  qualification  services  address  the  security 
requirements  of  a  directory  service.  There  arc  three  services 
which  make  up  the  service  qualification.  One  service  is  service 
control  which  sets  limits  on  the  use  of  resources  such  as  the 
extent  of  a  search  requested.  Another  service  is  security 
parameters  which  protects  directory  information  by  indicating 
security  level  or  type  of  protection  a  user  wishes.  The  third 
service  is  the  filter  service  which  defines  conditions  thut  must 
be  satisfied  so  flint  information  may  be  returned  to  the  user. 

The  directory  interrogation  service  provides  for  reading, 
comparing,  listing,  searching,  and  abandoning  a  query.  The 
directory  modification  service  supplies  services  for  adding 
entries,  removing  entries,  and  modifying  entries.  The  error 
messages  are  errors  and  referrals  to  another  service  when  one 
service  fails. 

Two  directory  protocols  a.c  defined.  One  is  the  Directory 
Access  I’rotocol  (DAP)  which  defines  the  communication 
between  users  and  the  directory.  The  other  protocol  is  the 
Directory  System  I’rotocol  (DSI’)  which  defines  the 
communication  within  the  directory;  this  protocol  addresses  a 
distributed  directory  service. 

The  specific  security  standards  being  developed  for  the 
Directory  Service  are  not  currently  included  ns  part,  of  the  set 
of  standards,  but  are  in  an  annex,  The  rationale  lor  keeping 
the  security  portions  out  of  the  standard  is  that  security  can 
be  considered  ns  a  local  matter  which  depends  on  the 
particular  security  policy  of  the  local  system.  This  justification 
appears  to  cover  up  a  lack  of  knowledge  about  security.  Effort 
needs  to  be  expended  to  define  a  useful  and  useable  set  of 
services. 

The  model  of  security  as  proposed  currently  [I'd]  consists  of 
two  aspects:  access  control  and  authentication.  The  control  or 
user  access  to  information  is  based  on  the  use  of  access  control 
attributes  such  as  user/application  identity,  authentication 
information,  or  lal-  ls  and  tiro  use  of  access  conditions  which 
relate  the  attributes  to  user  operations  on  information. 

For  access  control,  no  particular  services  are  defined.  However, 
mechanisms  arc  suggested.  These  mechanisms  arc  information 
on  access  conditions  and  access  control  lists;  authentication 
information  such  as  passwords;  capabilities;  and  labels. 

For  authentication,  three  types  of  services  arc  defined:  no 
authentication,  simple  authentication,  and  strong 
authentication.  For  both  access  control  and  authentication,  an 
operator  defined  as  BIND  is  to  be  used.  The  BIND  operator 
appears  to  associate  the  user-supplied  credentials  with  the 
user's  identity  and  deny  or  grant  access  as  appropriate. 

More  work  needs  to  be  done  to  deHne  a  security  model  and  an 
appropriate  set  of  security  services  for  the  Directory. 
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2. 1.4.3  OSI  Session,  Presentation,  and 
Common  Application  Services  (WG6) 

Within  WGG,  there  are  two  standards  activities.  One  activity 
is  a  proposed  security  addendum  to  the  Presentation  Layer 
Standards.  The  other  activity  has  been  the  development  of  an 
authentication  framework. 

2. 1.4. 3.1  Standards  for  Security  at  the 
Presentation  Layer.  The  Security  Addendum  to  the 
Presentation  Layer  [1  ttj  presents  an  argument  for  placing  data 
encryption  at  the  presentation  layer.  This  proposed  addendum 
is  a  preliminary  discussion  paper.  The  paper  asserts  that  data 
encryption  is  a  legitimate  concern  of  the  presentation  laver. 
The  service  offered  by  the  presentation  layer  is  protected  data 
transfer.  The  mechanism  suggested  for  supplying  this  service 
is  encryption. 

The  issues  which  the  paper  raises  are  the  following. 

I  The  encryption  function  should  be  invoked  on  all  user 
data  in  a  specific  presentation  context  rather  titan  on 
all  user  data  uii  the  presentation  connection. 

2.  The  transfer  syntaxes  and  mechanisms  should  be  kept 
separate. 

;i.  Compression  should  be  accomplished  before 
encryption  so  that  data  is  not  duplicated. 

■I.  Well-known  algorithms  for  compression  and 

encryption  should  be  registered. 

2.1 .4.3.2  Standard  for  Authentication.  The 

purpose  of  this  standard  is  to  add  services  for  authentication 
to  ISO  Still)  which  is  the  Association  Control  Service  Element 
(ACtSH)  definition.  This  first  draft  |14)  outlines  the  definition 
of  a  framework  for  authentication  by  providing  a  model  and 
specific  services  required  for  nut heiilicntion.  This  draft  also 
will  be  incorporated  into  the  Authentication  Framework.  The 
review  of  litis  document  is  applicable  to  the*  Authentication 
Framework. 

The  scope  of  the  standard,  as  staled  in  the  draft  document,  is 
to  specify  the  OKI  communication  services  necessary  to  support 
Application  Layer  authentication  for  connection-oriented 
operation.  The  authentication  services  will  be  available  for  use 
with  association  establishment  and  authentication  on  already 
established  associations.  Four  levels  of  authentication  are 
meant  to  Ire  supported:  no  iiulhclilirali  >n;  identification  of  the 
remote  peer  entity  only,  without  verification;  simple 
nulhrntieation  (passwords);  mid  strong  authentication 
(verification  using  cryptographic  techniques). 

The  problem  which  this  addendum  to  ISO  Slit!)  needs  to 
resolve  is  the  close  binding  of  services  with  mechanisms.  The 
definition  or  the  services  includes  the  definition  of  the 
mechanisms  the  services  should  invoke.  If  the  definitions  of 
services  and  of  mechanisms  call  In*  separated,  then  the 
standardization  of  authentication  services  should  lie  much 
simpler. 

2.2  Banking  (TC08) 

The  security  efforts  by  the  banking  community  nrc  well 
advanced  and  moving  into  new  areas  of  technology.  They 
have  addressed  the  use  of  encryption  for  protection  of  data 
and  are  looking  at  mechanisms  for  authentication  such  as 
smart  cards.  Figure  12  shows  the  organization  of  TC68 
security.  The  following  sections  describe  the  activities  of  each 
working  group  within  each  subcommittee  (SO). 

2.2.1  Electronic  Funds  Transfer  (SC2) 

The  security  activities  in  ISO.'TOliS'' iC2  are  taking  place  in 
WG2. 


2.2.1. 1  Wholesale  Banking  (WG2) 

WG2  has  produced  two  standards  for  security  to  define 
message  authentication  using  encryption  and  encryption 
algorithms  to  be  used  for  the  message  authentication.  They 
are  working  on  key  management  to  distribute  the  encryption 
keys. 

2. 2. 1.1.1  Message  Authentication  Standard. 

This  standard  (IS|  specifics  how  the  Message  Authentication 
Code  (MAC)  is  calculated.  The  standard  succinctly  defines  a 
MAC  ns  "»  data  fluid  attached  to  a  set  of  data  (i  t*.,  message) 
passing  between  correspondent  fimtlicinl  institutions  und 
transmitted  along  with  that  set  of  data."  Essentially,  the 
authentication  code  is  an  encrypted  checksum 

The  level  of  security  protection  provided  by  this  MAC  depends 
on  the  protection  of  the  authentication  key  and  I  he  strength  of 
the  algorithm  used  for  encryption. 


2. 2. 1.1. 2  Message  Authentication  Algorithm 
Standard,  This  standard  [l()|  specifics  the  Data  Encryption 
Algorithm  (DEA)  to  be  used  in  the  calculation  of  the  Message 
Authentication  Code.  The  I) LA  is  also  published  ns  ANSI 
X3.02  which  is  known  as  the  Data  Encryption  Standard  (DBS). 

2. 2. 1.1 .3  Wholesale  Key  Management 
Standard.  WG2  is  using  the  ANSI  standard  for  key 
management  [17]  which  specifies  the  key  management  for 
wholesale  financial  institutions.  Included  is  a  specification  of 
management  of  encryption  keys  mid  distribution  of  encryption 
keys. 

2.2.2  Information  Exchange  (SC5) 

This  subcommittee  has  no  drafts  of  documents  available. 
However,  some  documentation  of  the  work  should  be 
forthcoming  in  six  months.  The  two  areas  in  which  SC5  is 
working  arc  applications  for  financial  messages  and  security  in 
relation  to  smart  cards. 
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3.0  EUROPEAN  COMPUTER 

MANUFACTURER’S  ASSOCIATION  (ECMA) 

ECMA  is  a  regional  organization  in  Europe.  Its  forty-five 
members  are  European  computer  vendors.  The  security 
activities  within  ECMA  are  paralleling  those  of  ISO.  The 
current  focus  of  security  in  ECMA  is  within  ECMA  TC32. 
The  groups  within  TC32  which  are  doing  security  work  arc 
listed  below. 

TG2  -  Security  Aspects  of  Distributed  Interactive  Processing 

TGI  -  Security  Aspects  of  OSl  Management 

TG5  •  Security  in  Distributed  Office  Applications 

TGil  &  TG7  -  Security  Facilities  at  Lower  Layers  of  OSI  Model 

TOO  -  Security  Framework  for  Open  Systems 

Other  elements  in  ECMA  which  arc  addressing  security  arc 
listed  below. 

TC22  -  Security  of  Data  Base  Systems 
TC2I)  -  Security  Aspects  of  Documents 

HC'MA  has  stated  their  goals  of  establishing  liaisons  with  the 
ISO  groups  of  JTCI/SC18,  JTC1/SC20,  and  .1TC1/SC21  and 
with  CCITT  to  provide  security  standards  |18|. 

Tlie  mast  visible  aspect  of  the  ICCMA  work  in  ISO  has  been 
their  proposed  security  addendum  to  ISO  7*108  |l|  to  address 
general  security  services  required  by  distributed  applications 
The  purpose  of  this  work  is  to  define  general  services  in  order 
to  avoid  the  extensive  security  definitions  which  had  to  be 
done  for  the  specific  distributed  applications  of  Message 
Bundling  System  and  Directory  Service. 


4.0  INTERNATIONAL  TELEGRAPH  AND 
TELEPHONE  CONSULTATIVE 

COMMITTEE  (CCITT) 

CCITT  is  collaborating  witli  ISO  lo  produce  a  series  of 
documents  which  would  form  parts  of  a  multi-part 
International  Standard  in  ISO,  and  a  series  of 
Herommciidations  in  CCITT.  The  current  focus  has  been  on 
the  directory.  The  security  inspects  of  the  directory  work  have 
concent  rati  d  on  the  authentication  framework  for  the 
directory. 

4.1  Authentication  Framework  for  the  Directory 

The  Convergence  Document  for  Directory  Security  |l!)| 
describes  the  role  the  directory  plays  in  user  authentications  by 
providing  credentials  to  users.  There  are  two  aspects  to  this 
authentication:  services  must  lie  authenticated  by  the 
directory  in  order  to  obtain  credentials  of  a  user  anil  the 
credent  inis  obt  ained  from  the  directory  tire  used  to 
authenticate  the  user. 

Two  types  of  authentication  arc  defined:  simple 

authentication  and  strong  authentication.  Simple 
authentication  is  defined  as  the  use  or  a  user  name  and  an 
unencrypted  password.  Strong  authentication  is  defined  as  the 
Uef  of  public  key  cryptography,  specifically  the  cryptosystem 
specified  in  1)1’  0307,  more  commonly  known  ns  USA  (mimed 
after  the  authors  Kivcst,  Shamir,  and  Adclmnn  |20|). 

Although  the  title  of  the  document  is  authentication 
framework,  the  document  only  describes  two  particular 
mechanisms  for  authentication,  a  simple  one  and  a  strong  one. 
Within  tile  definition  of  the  mechanisms,  the  types  of 
mechanisms  the  directory  would  be  required  to  supply  arc 
defined.  There  is  no  separate  definition  of  services  or  of  which 
services  the  directory  could  supply. 


5.0  AMERICAN  NATIONAL  STANDARDS 
INSTITUTE  (ANSI) 

ANSI  is  tlie  United  States  industrial  standards  organization. 
ANSI  does  not  create  standards,  but  does  accredit 
organizations  and  committees  which  develop  the  standards. 
These  committees  are  American  National  Standards 
Committees  (ANSCs).  There  are  four  ANSCs:  tlie  Computer 
aad  Business  Equipment  Manufacturers  Association  (C'BICMA), 
the  Exchange  Onrriers  Standards  Association  (EOSA),  the 
Electronics  Industry  Association  (EIA),  nml  the  Institute  of 
Electrical  and  Electronic  Engineers  (IEEE).  The  security 
activities  which  support  ISO  arc  taking  place  in  CBEMA  in  the 
X3  committee. 

5.1  Data  Communications  (X3S3) 

X3S3  is  responsible  for  developing  standards  at  the  lower 
layers,  transport  and  below. 

5.2  Text!  Office  and  Pubiiahing  Systems  (X3V1) 

X3V1  is  responsible  for  standards  which  have  lo  do  with  the 
office  environment,  such  as  message  handling. 

5.3  Systems  Technology,  Data  Encryption  (X3T1) 

X3TI  develops  standards  for  secure  systems  based  on 
encryption  meehnnisms. 

5.4  Information  Processing  Systems  (X3T6) 

X3T5  is  the  standards  committee  responsible  for  Open  Systems 
interconnection  (OSI).  X3T5  corresponds  to  JTUI/Sdl  and 
is  organized  into  task  committees  whirl)  parallel  tin*  SC2I 
organization. 

5.4.1  OSI  Architecture  (X3TG.1) 

X3T5.I  is  responsible  for  tlie  development  of  OSI  Architecture 
X3T5.I  corresponds  to  ISO/JTCI/SC2I  'W'Cil.  The  current 
concern  of  X  3T.V !  in  security  is  to  assure  that  llic 
development  of  security  standards  continues  mid  makes  the 
best  use  of  llic  limited  security  expertise  in  networking.  To 
this  end,  X3T5.I  has  suggested  that  security  expertise  should 
lie  consolidnled  into  n  single  security  group,  in  llic  form  of  a 
security  inpporteur's  group,  in  S('2l/WGti.  The  mccliiigs  of 
this  group  should  lie  located  wherever  ciinnit  work  is 
occurring  in  security.  At  present,  tlie  work  in  security  services 
occurs  in  upper  layers  in  X3T.YG  and  NO'JI/WGti  |2I|. 

5.4.2  OSI  Management  Protocols  (X3T5.4) 

X3T5.4  is  responsible  for  the  development  of  OSI  Management 
I’rotocols  and  vocabulary  for  OSI  management.  \3T.V ! 
corresponds  to  1SO/JTC1/SC2I/WGI  and  works  on  any  issues 
which  surface  in  VVC',1.  Currently  X3T*r>  I  is  submitting 
revisions  to  the  Security  Management-  Service  Definition,  I’art 
7  |«|. 

5.4.3  Application,  Presentation,  and  Session  Layers 
(X3T5.5) 

X3T5.5  is  responsible  for  tlie  development  of  protocols  at  l  lie 
upper  layers  of  tlie  OSI  architecture.  X3T.r>..r>  corresponds  to 
ISO/JTC1/SC2I/WGB. 

6.0  MANUFACTURING  AUTOMATION 
PROTOCOL/TECHNICAL  OFFICE 

PROTOCOL  (MAP/ TOP) 

Currently,  there  is  a  group  v.ithin  MAI'/TOB  which  is 
organized  to  hyjk  at  security,  but  it  has  no  output  and  is  not 
very  active. 
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7.0  NATIONAL  BUREAU  OF  STANDARDS 
(NBS)  IMPLEMENTOR'S  WORKSHOP 

Within  the  Implementor’s  Workshop  is  n  Security  Special 
Interest  Group,  the  Security  S1G.  The  goal  of  the  Security 
SIG,  as  stated  by  the  group,  is  to  develop  an  overall  OSI 
Security  Architecture  which  is  consistent  with  the  OSI 
reference  model  and  which  economically  satisfies  the  primary 
security  needs  of  both  the  commercial  and  Government  sectors. 

The  areas  currently  being  addressed  by  the  Security  SIG  arc  a 
general  security  model  (extension  to  DIS  7498-2),  a  security 
management  model,  security  activities  at  Urn  various  layers 
such  as  the  proposed  Security  Protocol  addendum  to  DIS  8073 
for  transport  security,  and  application  security.  The  areas  of 
application  security  are  the  Message  Handling  System 
application  and  the  Directory  Systems  application. 

The  Message  Handling  System  standards,  according  to  the 
Security  SIG’s  review,  will  provide  u  comprehensive 
specification  for  message  handling  comprising  any  numbci  of 
cooperating  open  systems.  The  Message  Handling  System  and 
services  enable  users  to  exchange  messages  on  a  xtorc-nnd- 
I'orwnrd  basis. 

The  Directory  Systems  standards,  according  to  the  Security 
SIG’s  review,  facilitate  the  interconnection  of  information 
p-oeessiltg  systems  to  provide  directory  xerviecs.  The  directory 
provides  the  directory  capabilities  miuinal  by  OSI 
applications,  management,  other  OSI  layer  entities,  and 
telecommunications  services. 

The  area  where  work  is  complete  is  the  listing  of  the 
desirability  of  the  security  services  defined  in  DIS  7.198-2  in 
each  layer.  A  rating  of  High,  Medium  or  Low  is  determined  for 
each  service  at  each  layer.  The  matrix  which  describes  the 
desirability  can  be  used  as  a  guide  for  choosing  llie  appropriate 
services  for  various  applications. 

The  Security  SIG  has  the  opportunity  to  influence  the  security 
of  all  the  ISO  standards.  The  SIC!  has  established  a  core  of 
people  to  follow  the  wo.k  in  various  ureas  and  to  keep  the  SiU 
apprised  of  any  developments  while  they  work  on  the  security 
standards  to  be  included  in  the  OSI  Implementor’s  Agreements 


8.0  DOD  PROGRAMS 

The  DoD  programs  which  are  going  to  use  ISO/OSI  protocols 
have  only  committed  to  use  the  security  architecture 
document,  DIS  7498-2.  Thus  they  are  committed  to  the  basic 
premise  of  the  security  architecture,  but  not  to  the  specific 
standards  being  developed  within  this  architecture,  in  the  face 
of  no  commitment,  it  is  presumed  that  the  DoD  programs  will 
develop  their  own  security  standards. 

8.1  Secure  Data  Network  System  (SDNS) 

SDNS  is  a  research  program  which  promulgates  the  design  of 
the  next  generation  of  secure  computer  communications 
networks,  The  current  efforts  are  the  architecture,  the 
services,  the  protocols,  and  the  products.  The  SDNS  products 
will  be  developed  and  fielded  under  NSA’s  commercial 
COMSEC  Endorsement  Program  (CCER) 

SDNS  is  defining  standard  security  services  in  layers  2,  3,  4, 
and  7;  these  service  definitions  arc  claimed  to  be  consistent 
with  those  defined  in  ISO  74°8-2.  There  are  many  working 
groups  within  the  SDNS  project  trying  to  resolve  the  various 
issues  such  as  access  control,  key  management,  and  protocol 
definition.  The  intent  is  to  promote  SDNS  in  the  OSI  arena  so 
that  cleared  United  States'  vendors  will  build  SDNS  products. 


8.2  Internet  and  DDN 

The  Internet  and  DDN  arc  requited  by  DCA  to  transition  to 
OSI  protocols  by  1900.  The  vehicle  for  DoD  transition  to  OSI 
protocols  is  the  Government  OSI  Profile  (GOSIP).  This  profile 
is  to  be  the  standard  reference  for  all  Federal  Government 
Agencies  to  use  when  acquiring  and  operating  ADI*  systems  or 
services  and  communications  systems  or  services  intended  to 
conform  to  the  OSI  protocols.  Currently  GOSH*  (Version  I, 
April  1987)  includes  two  applications:  File  Transfer  and 
Management  (FTAM)  ami  Message  Handling  (CCTI  I  X.-100) 
and  four  networking  technologies:  long-haul  network 
connectivity  (CC1TT  X.25),  CSMA/CD  (SEEK  802.3),  Token 
Dus  (IEEE  802.4),  nnd  Token  Ring  (IEEE  802. 5).  The  specific 
options  and  parameters  specified  tor  each  protocol  are  based  on 
agreements  reached  at  the  National  Liurcaii  of  Standards 
Implementor’s  Workshops. 


0.0  SUMMARY  OF  ISSUES 

Standards  for  security  bused  on  the  ISO/OSI  model  are  a 
fledgling  area.  Work  has  begun  on  these  standards,  but  there 
is  much  left  to  do  before  security  standards  reach  the 
International  Standard  status.  Figure  13  summarizes  the 
current  activities  in  security  standards  for  the  organizations 
shown  in  Figure  1.  Many  of  these  standards  are  in  preliminary 
draft  paper  form;  there  is  additional  work  to  lie  done  belore 
they  call  be  useful  even  its  a  guide  for  how  security  cull  be 
integrated  into  the  Basic  OSI  Reference  Model. 


El 

ECMA 

ccit  r 

9 

E35j 

jgj| 

a 

a 

gs 

ADDliCvIttOM 

m 

Hi 

13 

PfWtvntfltrOn 

11 

© 

El 

■ 

■ 

■ 

3o88ton 

■ 

■ 

■ 

S 

IrnrsoOft 

EH 

El 

E 

Fdel 

■ 

EE3 

Neiwork 

_ 

m 

m 

© 

Dflia  UnK 

m 

m\ 

Physical 

— 

■ 

■ 

m 

Figure  13.  Security  Standard  Activity  Summary 


The  areas  which  have  not  yet  been  addressed  are:  LAN 
Security  and  any  specific  security  concerns  which  are  different 
from  Long  Haul  networks  and  Network  Laver  Security  or  at- 
least  little  work  lias  been  done  here  except  liy  the  United 
States’  DoD. 

The  areas  which  need  more  work  are:  at  the  application  layer: 
Security  Management,  Directory  Security;  at  the  presentation 
layer:  more  analysis  of  what  security  at  this  means  although 
this  does  appear  to  be  the  appropriate  layer  in  which  to 
perform  encryption  as  it  i3  meant  to  translate  from  one 
representation  of  data  to  another;  at  the  architecture  level: 
frameworks  or  models  of  tile  security  services. 

The  work  in  security  standards  which  is  progressing  well  is  the 
Message  Handling  Security  which  makes  a  valiant  attempt  at  a 
thorough  definition  of  security.  The  ECMA  work  for  security 
service  definition  of  distributed  applications  is  a  much-needed 
effort  which  should  be  an  area  for  immediate  concentration. 
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The  Banking  community  has  made  the  most  progress  at 
addressing  security  problems  in  the  area  of  encryption  and  ill 


protecting  their  data  using  encryption  techniques.  The 
Information  Processing  area  should  follow  their  lead  in 
addressing  manageable  problems  and  not  try  to  solve 
everything 

The  overall  status  of  standard*  for  security  based  on  the 
ISO/OSl  model  is  reflected  in  the  NBS  Security  SIG  whose 
purpose  is  o  develop  Implementor's  Agreements.  The  Security 
SIG  is  instead  discussing  models  of  secure  services,  because 
there  are  no  standards  on  which  to  base  Agreements.  This 
area  is  moving  quickly,  but  more  expertise  is  needed  to 
contribute  to  the  efforts. 
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ABSTRACT 


Sun  Microsystems  is  currently  developing  enhancements  to  its  SunOS  operating  system  to  create  a 
Trusted  Computing  Base  (TCB)  to  be  evaluated  at  the  B1  level.  Since  the  Sun  system  is  a 
distributed  collection  of  workstations  and  servers  connected  by  a  network,  network  security  is  a 
crucial  pan  of  the  design.  This  paper  describes  the  problems  addressed  and  solutions  found  for 
secure  packet  routing  and  for  passing  mandatory  access  control  labels  over  a  network  while 
remaining  compatible  with  the  existing  SunOS  system  and  with  existing  networking  standards. 


1.  Introduction 

Sun  Microsystems  is  currently  working  on  a  secure  version  of  the 
SunOS  operating  system  to  be  evaluated  at  the  B 1  level.  In  this 
system,  security  labels  urc  used  to  provide  mandatory  access  con¬ 
trol  (MAC).  This  paper  discusses  Sun’s  solution  for  passing  MAC 
labels  over  a  network.  The  Secure  SunOS  architecture  considers  a 
collection  of  workstations  as  a  single  distributed  TCB.  For  evalua¬ 
tion  purposes,  an  entire  contiguration  of  Secure  SunOS  Hosts  is 
considered  to  be  a  single  “system”,  all  of  whose  hardware  must 
be  physically  secure.  The  mechanism  used  for  network  communi¬ 
cation  in  this  system  is  sockets.  A  socket  is  an  end-point  for  com¬ 
munication  that  will  have  a  MAC  label.  Just  us  MAC  in  accom¬ 
plished  in  the  file  system  by  labeling  the  files,  so  will  labeling  the 
sockets  facilitate  MAC  for  networking.  In  fact,  sockets  contribute 
to  the  single  system  image  of  the  SunOS  system. 

Because  the  system  is  distributed,  there  ure  problems  to  be 
addressed  thut  do  not  need  to  be  addressed  by  single  host  systems. 
While  the  end-points  for  communication  across  the  network  (the 
sockets)  may  be  easily  labeled,  the  problem  of  getting  this  label 
information  across  the  network  needed  further  investigation. 

While  researching  secure  networking,  Sun  also  found  that  custo¬ 
mer  acceptance  imposed  conditions  on  the  design.  A  major  issue 
is  thut  of  trusting  foreign  (non-Sun)  hosts  on  a  network.  Sun  has 
received  numerous  requests  from  customers  who  wish  to  attach 
other  vendor’s  hardware  in  a  secure  way  to  the  Secure  SunOS  ys- 
tem.  This  configuration  would  not  be  covered  by  the  NCSC 
evaluation  but  it  is  a  highly  useful  and  desired  product  feature.  By 
attaching  foreign  hosts,  customers  have  an  easy  migration  path 
from  the  existing  equipment  to  an  evaluatuble  Secure  SunOS  sys¬ 
tem.  However,  this  addition  does  raise  serious  new  problems 
which  must  be  dealt  with  in  order  to  maintain  a  secure  system. 


Figure  1:  The  Evaluated  Configuration 

SunOS  and  NFS  ure  registered  trademarks  of  Sun  Microsystems,  Inc. 

UNIX  is  a  registered  trademark  of  AT&T. 
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Another  desirable  feature  is  the  ability  to  limit  the  level  of  trust  of 
a  network.  For  the  evaluated  configuration,  all  networks  would  be 
trusted  at  the  entire  range  of  security  labels  in  the  Secure  SunOS 
system  (system-low  to  system-high).  Other  configurations  may 
.find  it  useful  to  be  able  to  reflect  differing  degrees  of  trust  on  dif¬ 
ferent  networks.  For  example,  a  network  completely  made  up  of 
Secure  SunOS  Hosts  might  have  a  higher  degree  of  trust  than  a 
network  which  contains  Foreign  Hosts.  Again,  this  raises  new 
issues.  One  such  issue  is  secure  routing.  Given  that  different  net¬ 
works  have  different  levels  of  trust,  how  does  one  machine  send  a 
packet  through  several  gateways  (IP  routers)  to  a  remote  destina¬ 
tion  and  guarantee  that  all  intervening  networks  and  hosts  are 
allowed  to  carry  a  packet  at  that  level  of  security? 

2.  The  Overall  Problem 

The  Secure  SunOS  TCB  is  made  up  of  a  collection  of  workstations 
as  shown  in  Figure  1.  It  is  very  difficult  to  ensure  security  on  a 
system  which  is  distributed  over  several  hosts.  Performing  access 
control  decisions  between  processes  on  the  same  host  is  relatively 
easy  since  the  operating  system  has  all  the  information  necessary 
to  make  such  decisions.  For  processes  on  different  hosts,  this  is 
not  true.  The  current  SunOS  system  uses  sockets  and  the 
ARPAnet  standard  low-level  protocols  (TCP,  UDP,  and  IP)  to  do 
network  communications.  The  operating  system  on  one  host 
knows  about  the  socket  on  the  other  host  but  does  not  know  about 
the  remote  process  and  its  label.  This  label  information  must  be 
transmitted  from  one  host  to  the  other.  Compounding  this  “labels 
over  the  network"  problem  is  the  issue  of  Sun’s  stated  corporate 
objeetive  of  standards  adherence.  Thus  there  arc  constraints  posed 
by  the  goals  of  the  Secure  SunOS  system. 


2.1.  The  Guals  of  SECURE  SunOS 

A  summary  of  the  goals  of  the  Secure  SunOS  system  are  listed 
below.  The  goals  also  formed  design  constraints.  As  presented  in 
|Sun87],  these  goals  are 

( 1  ]  Conformance  With  NCSC  B 1  Criteria 

12)  Conformance  With  IEEE  PI 003  (I'OSIX) 

[31  Conformance  To  Standard  SunOS 

14[  Maintenance  of  UNIX  “Look  And  Feel" 

[51  Functionality  in  Government  and  Commercial  Applications 

16)  Minimal  External  Changes 

[7j  Operation  In  Standurd  Sun  Network 

[81  Extensibility  To  Future  Security  Offerings 

2.2.  Constraints  Driven  By  These  Goals 

These  goals  uie  in  conflict  witn  each  other.  For  example,  u  POS1X 
conforming  secure  system  which  is  backwards  compatible  to  the 
existing  SunOS  system  with  the  same  UNIX  “look  and  feel”  and 
minimal  external  changes  may  not  be  possible. 

The  Secure  SunOS  system  must  conform  to  the  standard  SunOS 
system  und  there  must  be  minimal  external  changes.  The  current 
.  system  uses  sockets  and  the  ARPAnet  low-level  protocols,  yet  the 
protocols  currently  defined  are  not  sufficient  for  a  B 1  system.  The 
current  protocols  do  not  provide  the  label  information  necessary  to 
make  the  correct  access  control  decisions.  However,  a  mechanism 
must  still  be  found  to  pass  labels  across  the  network  using  these 
existing  mechanisms.  In  particular,  custor  applications  which 
use  sockets  must  be  made  to  run  securely  witn  NO  modifications. 


To  compound  the  problem  it  must  be  possible  for  privileged 
servers  (part  of  the  TCB)  to  bypass  the  access  control  decision  of 
the  socket  mechanism  and  instead  make  access  control  decision  on 
their  own.  In  other  words,  label-cognizant  servers  must  have  a 
way  to  handle  multiple  clients  at  different  labels.  Finally,  it  is 
highly  desirable  to  have  unprivileged  servers  be  able  to  respond  to 
multiple  clients  where  the  clients  may  be  at  different  labels,  and 
these  servers  should  be  able  to  run  securely  with  no  modifications. 

At  the  time  of  this  writing,  Sun  knows  of  no  available  products 
that  overcome  these  problems  and  accomplish  these  goals. 

3.  Original  Solutions  Which  Were  Rejected 

Sun  looked  at  and  rejected  several  solutions  to  the  problem  of  pro¬ 
viding  MAC  information  across  sockets.  This  paper  will  briefly 
touch  on  some  of  these. 

3.1.  Restricting  Socket  Usage  To  Privileged  Processes 

One  of  Sun’s  first  proposals  was  to  restrict  sockets  to  privileged 
processes  only  (only  the  super-user  could  use  sockets).  This  would 
have  allowed  some  important  SunOS  programs  to  continue  work¬ 
ing  (NFS,  rep,  rlogin,  etc.),  though  in  those  eases  the  server  and 
client  programs  would  have  needed  to  be  modified  to  do  a  label- 
checking  handshake  before  performing  the  requested  operation. 
This  was  not  considered  u  serious  problem,  since  those  clients  and 
servers  are  already  privileged  and  would  have  required 
modification  regardless  of  the  approach  chosen. 

The  disadvantage  of  this  simple  restriction  was  that  it  broke  (A)  all 
unprivileged  users  of  the  Yellow  Pages  (YP)  global  database 
look-up  services  (such  as  Is),  (B)  suntools  and  SunView  in  general, 
which  use  sockets  to  communicate  among  window-using 
processes,  and  (C)  all  miscellaneous  unprivileged  uses  of  sockets 
(perfmeter,  user  telnet,  Ipr,  Umfy,  Alis,  etc.).  More  importantly 
this  solution  directly  conflicted  with  the  goals  of  conformance  to 
standard  SunOS  and  minimal  external  changes. 


3.2.  Restricting  Socket  Usuge  To  Single  Hosts  With  a 
"Forwarding  Daemon” 

This  proposal  required  that  the  operating  system  associate  a  label 
with  each  socket  (the  label  being  that  of  the  process  that  created 
the  socket),  and  check  that  this  label  was  equal  to  the  label  of  any 
process  connecting  or  sending  to  the  socket.  This  check  would 
have  been  performed  only  for  actions  performed  by  unprivileged 
processes,  und  unprivileged  processes  would  only  have  been  per¬ 
mitted  to  communicate  with  sockets  on  the  same  host.  In  this  case 
since  both  processes  would  have  been  on  the  same  host,  the  operat¬ 
ing  system  would  have  had  all  the  information  it  needed. 

To  extend  this  mechunism  beyond  a  single  host,  a  "forwarding 
daemon”  was  proposed  which  would  have  been  a  privileged  pro¬ 
cess  which  allowed  communication  between  hosts  by  doing  the 
mediation  itself.  The  disadvantage  of  this  proposal  is  that  applica¬ 
tions  would  have  had  to  change  to  use  the  “forwarding  daemon”. 

3.3.  Restricting  Socket  Usage  to  system-low  Processes 

This  proposal  built  on  the  proposal  above  by  allowing  multi-host 
socket  usage  if  both  processes  were  running  with  the  system-low 
label.  This  permitted  existing  applications  to  run  as  long  as  the 
users  or  processes  were  at  system-  low.  While  this  was  seen  as  an 
improvement  to  the  above  proposals,  it  was  unduly  restrictive  and 
of  limited  utility. 
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4.  Chosen  Solution 

To  overcome  these  restrictions,  the  chosen  solution  associates 
labels  with  packets.  Thus,  the  label  information  is  provided  to  the 
operating  systems  on  both  hosts.  Since  the  IP  standard  already 
provides  for  options  in  the  packet  header,  this  mechanism  has  been 
chosen.  The  security  label  is  put  into  a  new  label  option  in  the  IP 
packet  header.  This  label  option  is  a  requisite  for  secure  commun¬ 
ications. 

Sun’s  solution  sets  a  label  in  the  socket  to  the  label  of  the  process 
which  creates  it.  This  label  is  appended  to  the  packets  as  an  IP 
label  option.  The  destination  host  then  checks  the  label  on  the 
packet.  If  the  received  packet  label  is  equal  to  the  label  of  the  des¬ 
tination  socket  (the  target  process),  the  packet  is  delivered;  other¬ 
wise,  it  is  dropped.  If  the  packet  is  dropped,  an  audit  message  is 
generated,  and  the  sending  process  is  notified  that  access  is  denied. 
All  socket  communication  is  considered  to  be  bi-directional  in 
some  sense  (either  explicitly,  or  in  the  form  of  acknowledge¬ 
ments),  so  unprivileged  processes  may  only  communicate  via 
sockets  if  their  lubels  are  equal.  Figure  2  shows  communication 
between  processes  on  two  hosts.  Only  the  two  processes  running 
at  the  same  label  are  allowed  to  communicate. 


Host  A  Host  B 


As  mentioned  earlier,  it  is  necessary  for  privileged  servers  (part  of 
the  TCB)  to  be  able  to  make  access  control  decisions  themselves 
instead  of  being  constrained  by  the  socket  label.  For  example,  the 
network  file  system  (NFS)  needs  to  be  able  to  respond  to  clients  at 
any  label  regardless  of  its  own  socket  label.  For  this  reason, 
privileged  processes  are  allowed  to  override  the  access  control 
decisions  made  by  the  socket  code  by  setting  a  new  socket  option, 
the  unconstrained  option.  A  privileged  process  is  trusted  to  make 
the  appropriate  access  control  decision.  A  privileged  processes  is 
also  allowed  to  send  packets  at  any  label.  New  system  calls  are 
provided  to  send  at  a  different  label  than  the  label  in  the  socket. 
New  systems  calls  are  also  provided  to  return  the  label  from  the 
packet  so  that  the  privileged  process  has  the  information  to  make 
the  proper  access  control  decisions.  The  existing  routines  get- 
sac  kopti)  and  setsockopti )  are  modified  to  set  and  get  the  socket 
label  and  the  new  unconstrained  opdon.  Communication  with  a 
privileged  process  is  shown  in  Figure  3. 

It  is  also  desirable  for  unprivileged  servers  to  be  able  to  respond  to 
clients  at  varying  labels.  In  the  SunOS  system,  there  is  an  existing 
server,  Inetd,  which  connects  servers  and  clients.  As  it  exists, 
inetd  gets  information  about  servers  from  a  configuration  file. 
Inetd  listens  for  connections  to  the  setvices  in  this  file.  When  a 
connection  is  found,  it  invokes  the  server  daemon  specified.  In  the 
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Figure  3:  Privileged  Socket  Communication 


Secure  SunOS  system,  inetd  is  modified  to  use  the  new  uncon¬ 
strained  option  on  its  sockets.  It  gets  the  label  from  the  packet  sent 
by  the  client  and  invokes  the  appropriate  server  daemon  at  that 
label.  Thus,  any  application  listed  in  inetd’i  configuration  file  will 
be  able  to  securely  communicate  with  clients  at  multiple  labels 
with  no  change  to  the  existing  code.  In  Figure  4,  inetd  is  used  to 
allow  communication  between  an  rlogin  client  and  its  server. 
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Figure  4:  Multilevel  Socket  Communication  Using  Inetd 


This  solution  requires  no  changes  to  either  existing  user  or  server 
applications,  All  applications  may  run  if  the  processes  on  either 
side  of  the  socket  are  at  the  same  label.  For  servers  that  serve 
clients  at  different  labels,  again  no  changes  are  necessary,  since 
inetd  will  do  the  access  control  decision  for  the  application. 

This  solution  has  the  advantage  of  using  well-understood  protocols 
with  fairly  localized  extensions.  This  solution  will  have  the  look 
and  feel  of  the  UNIX  system.  The  only  difference  seen  by  users  is 
that  they  will  get  errors  if  there  is  a  label  mismatch  between  two 
processes  wishing  to  communicate, 

5.  Non-evaluated  Extensions 

The  solution  stated  above  is  necessary  for  the  evaluated 
configurations  but  not  sufficient  for  the  existing  customer  base. 
Customers  require  that  investment  in  existing  hardware  be 
preserved.  In  particular,  the  Secure  SunOS  system  must  work 
safely  when  connected  to  o titer  vendors’  gear  (Foreign  Hosts), 
The  desired  configuration  is  shown  in  Figure  5. 
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Another  desired  feature  restricts  the  label  range  of  u  network,  This 
allows  customers  to  restrict  communication  with  un  environmen¬ 
tally  less  safe  network.  Communication  over  the  restricted  net¬ 
work  would  only  be  allowed  for  originators  within  its  range, 
Packets  at  labels  outside  the  network  range  would  never  go  onto 
the  network. 

Both  these  features  raise  new  issues.  The  following  sections  will 
discuss  the  issues  and  how  they  are  dealt  with, 

5.1.  Foreign  Hosts 

5.1.1.  The  Problem 

Foreign  Hosts  will  not  know  how  to  send  or  receive  labeled  IP 
packets.  Thus,  Secure  SunOS  Hosts  will  need  to  communicate 
with  these  hosts  without  using  packet  labels.  The  Secure  SunOS 
Hosts  will  need  to  know  what  label  of  information  to  use  for  each 
Foreign  Host  and  will  need  to  only  send  and  receive  information  at 
this  label.  Figure  6  shows  the  desired  result  of  communication 
between  a  and  a  Foreign  Host, 
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Obviously  adding  a  Secure  SunOS  system  to  a  network  docs  not 
make  Foreign  Hosts  secure.  There  are  rules  that  Foreign  Hosts 
must  follow  in  order  to  be  considered  safe.  They  are  trusted  not  to 
read  packets  which  are  not  addressed  to  them.  They  must  act 
benignly  if  a  labeled  packet  is  sent  to  them.  Foreign  Hosts  arc  also 
trusted  not  to  communicate  with  each  other  if  they  are  at  different 
labels.  Foreign  Hosts  are  trusted  to  be  well-behaved  in  general: 
they  should  not  pretend  to  be  another  host  and  should  not  try  to  act 
as  a  server  to  Secure  SunOS  Hosts  which  are  booting  or  asking  for 
Yellow  Pages  Information.  Despite  these  assumptions  about 
Foreign  Hosts,  the  problem  of  how  to  coexist  safely  with  hosts  that 
do  not  understand  the  IP  label  option  needed  further  investigation. 

5.1.2.  Rejected  Solutions 

The  first  solution  considered  for  this  problem  was  to  define  that 
Foreign  Hosts  were  always  at  system-low.  This  seemed  unduly 
restrictive.  It  also  did  not  address  the  real  problem  of  determining 
whielt  hosts  were  Foreign  Hosts  and  which  were  Secure  SunOS 
Hosts.  Since  it  was  already  necessary  to  keep  information  about 
which  hosts  were  the  Foreign  Hosts,  label  information  about  those 
hosts  could  also  be  kept.  In  fact,  Information  about  all  the  hosts 
had  to  be  kept  in  order  to  distinguish  between  Foreign  Hosts, 
Secure  SunOS  Hosts,  and  hosts  which  were  unknown. 

This  raised  the  new  problem  of  how  to  keep  this  information.  The 
next  solution  was  fairly  obvious:  keep  a  database  which  had  infor¬ 
mation  about  every  host  on  the  internet.  This  was  also  quite  res¬ 
trictive  since  it  meant  that  a  host  could  only  communicate  with 
hosts  in  its  database.  Adding  a  host  anywhere  on  the  internet 
would  have  required  updating  every  other  host.  Along  with  being 
an  administrative  nightmare,  this  restriction  would  have  meant  that 
connection  to  the  ARPAnet  would  never  have  been  allowed  since 
it  would  have  been  impossible  to  have  a  database  of  all  other  hosts 
on  the  ARPAnet. 
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5.1.3.  Chosen  Sulution 

Sun’s  solution  allows  broader  freedon  of  communication.  Each 
host  is  not  required  to  know  about  all  the  other  hosts  on  the  inter¬ 
net.  Instead  it  uses  the  Secure  SunOS  gatewuys  to  take  care  of 
access  control  decision  for  all  hosts  to  which  it  is  not  directly  con¬ 
nected.  if  Host  A  is  not  on  the  same  network  us  Host  B,  Host  A 
will  send  a  labeled  IP  packet  to  a  gateway.  This  gateway  will  for¬ 
ward  it  on  to  any  additional  gateways  until  the  packet  reaches  a 
gateway  which  is  directly  connected  to  Host  B.  That  gateway  will 
determine  whether  Host  B  is  a  Foreign  Host.  If  Host  B  is  a 
Foreign  1  lost,  the  gateway  will  determine  whether  communication 
with  Host  B  is  allowed  at  the  label  in  the  packet’s  IP  label  option. 
If  communication  is  allowed,  the  IP  label  option  will  be  stripped 
from  the  packet,  and  the  packet  will  be  delivered  to  Host  B.  If 
communication  is  not  allowed,  the  gateway  will  return  information 
to  Host  A  that  the  packet  was  not  delivered.  Finally,  if  the  gate¬ 
way  determines  that  Host  B  is  a  Secure  SunOS  Host,  then  it  will 
forward  the  packet  to  I  lost  B  where  the  appropriate  access  control 
decision  will  be  made. 

Host  B 


I  lost  A  Gateway  label  b 


Figure  7:  Communication  With  u  Foreign  Host 
Through  a  (Jutewuy 


Correspondingly,  it’  u  Secure  SunOS  gateway  receives  a  packet 
from  a  Foreign  Host,  it  will  add  to  the  packet  an  IP  label  option 
with  tlte  label  of  the  Foreign  Host,  it  will  then  forward  the  packet 
through  intermediate  gateways  until  finally  it  reaches  a  gatewuy 
directly  connected  to  tlte  destination  host.  This  gateway  will  make 
the  access  control  decisions  as  described  in  the  paragraph  ttbovc. 
Note  that  if  there  is  just  one  gateway  between  two  Foreign  Hosts, 
the  gateway  would  not  need  to  add  an  IP  label  option  and  then 
strip  it. 

This  allows  Foreign  Hosts  to  act  as  single-labeled  gatewuys. 
Since  Foreign  Hosts  are  trusted  to  only  communicate  with  other 
Foreign  Hosts  at  their  own  labels,  Secure  SunOS  Hosts  can  assume 
that  any  pucket  received  front  u  single-lube  gatewuy  should  only 
be  uecepted  for  processes  running  at  the  corresponding  label. 
These  Secure  SunOS  Hosts  will  also  only  send  information  at  the 
gutewuy's  label  through  the  single-label  guteway. 

Hosts  ate  not  required  to  keep  information  about  every  host  on  the 
internet.  Instead,  a  host  only  needs  to  know  about  hosts  on  its  own 
network.  Gateways  provide  the  needed  access  control  checking 
for  other  hosts.  The  following  decision  is  made  by  each  host  and 
gateway  in  determining  whether  to  add  an  IP  label  option  to  the 
packet:  if  the  immediate  destination  of  the  packet  is  a  Foreign 
Host,  do  not  label  the  pucket,  otherwise  label  it.  The  immediate 
destination  is  the  final  destination  if  the  hosts  are  on  the  same  net¬ 
work,  otherwise  the  immediate  destination  i.;  a  gateway. 

One  interesting  point  is  diskless  machines.  When  a  diskless 
machine  is  booting,  it  has  no  knowledge  of  any  hosts  including 
itself.  This  is  solved  by  treating  diskless  machines  as  Foreign 
Hosts  at  the  system-low  label  while  they  are  booting.  Once  the 
diskless  machine  has  sufficient  knowledge  about  labels,  it  is 
returned  to  its  status  us  a  Secure  SunOS  Host, 


5.2,  Secure  Routing  (Allowing  Networks  With  a  Restricted 
Label  Range) 

The  other  desired  extension  to  the  Secure  SunOS  system  is  the 
ability  to  restrict  the  range  of  communication  allowed  on  a  net¬ 
work.  This  feature  might  be  used  for  a  network  which  includes  a 
Foreign  Host.  It  might  also  be  used  for  a  link  between  two  build¬ 
ing  networks  as  shown  in  Figure  8, 


Figure  8:  Extensions  For  Restricted  Networks 


5.2.1.  The  Problem 

When  an  IP  packet  is  transmitted  from  u  host,  the  lowest  layer 
softwurc  module  must  choose  a  network  interface  to  use.  This  is 
easy  if  the  packet  is  addressed  to  a  host  attached  to  a  local  net¬ 
work.  If  the  sending  host  docs  not  huve  u  direct  connection  to  the 
destination  network,  it  must  select  another  host  to  use  us  a  gate¬ 
way.  This  choice  is  more  difficult:  there  may  be  several  candidate 
gateways,  each  able  to  correctly  deliver  the  packet,  but  some  of 
these  may  provide  better  (shorter)  pnths  to  the  destination  than  oth¬ 
ers. 

A  routing  protocol  is  used  to  help  make  these  decisions.  Routing 
daemons  on  every  host  exchange  information  about  known  routes 
ut  short  intervals.  When  these  daemons  start  up,  they  only  know 
about  networks  to  which  they  are  directly  attached.  This  informa¬ 
tion  is  gradually  dispersed  umong  all  the  routers  in  an  internet  so 
that  each  router  eventually  learns  about  routes  to  all  networks. 

In  the  existing  SunOS  system,  Sun  uses  the  distance  to  a  host,  or 
hop  count,  as  a  measure  of  the  cost  of  a  route.  Sun  cun  use  this 
information  to  reduce  the  size  of  local  routing  information,  by  only 
storing  the  best  route  to  a  network. 

in  the  Secure  SunOS  system,  each  network  has  a  label  range  asso¬ 
ciated  with  it.  Hosts  attached  to  the  network  arc  only  prepared  to 
uccept  traffic  which  contains  a  label  within  the  network  range. 
Herein  lies  the  routing  problem  in  a  secure  network:  a  packet 
which  is  sent  along  an  otherwise  correct  route  may  be  discarded 
before  getting  to  the  destination  because  it  encountered  u  network 
whose  label  range  did  not  include  the  label  of  the  packet  in  transit. 
As  illustrated  in  Figure  9,  a  packet  labeled  f  sent  from  Host  A  to 
Host  B  will  be  dropped  by  Host  Y,  so  it  must  be  sent  through  Host 
X.  Since  both  paths  have  the  same  cost,  the  existing  route  protocol 
will  only  know  about  one  of  the  paths. 
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F!  i’ll  re  9:  The  Routing  Prublcm 


5.2.2.  Rejected  Solutions 

Initially,  Sun  thought  the  problem  could  be  solved  by  milking  ull 
gateways  busted,  in  some  sense.  This  would  have  enabled  them  to 
pass  traffic,  which  would  otherwise  not  huve  been  allowed,  along 
into  the  host  containing  the  gateway.  Forwarded  packets  would 
never  have  been  passed  to  higher  level  protocol  modules,  or  out  of 
the  operating  system,  so  a  user  process  could  never  huve  acquired 
them. 

The  problem  with  this  approach  wus  that  it  disallowed  isolation  of 
physical  networks  using  purely  software  constructs.  If  an  internet¬ 
work  had  a  small  set  of  networks  which  required  strong  security 
measures,  such  us  hardware  encryption,  it  would  have  been  neces¬ 
sary  to  take  such  steps  on  all  reachable  networks.  Since  the  gate¬ 
ways  would  have  forwarded  packets  in  an  uncontrolled  manner,  a 
fault  in  one  of  these  secure  networks  might  have  caused  traffic  to 
be  redirected  through  another,  less  secure,  network.  For  the  exam¬ 
ple  shown  in  Figure  9,  traffic  from  Host  B  to  Host  A  ut  label  f 
should  go  through  Host  X.  Using  busted  gateways,  it  might  have 
gone  through  Host  Y.  There  would  have  been  no  way  to  isolate 
Network  2. 


Another  approach  was  to  use  static  routes.  Each  forwarded  packet 
could  have  used  the  IP  source  route  option,  which  would  have 
fully  specified  the  path  to  be  taken.  An  adminisbator  would  have 
been  required  to  set  up  routes  for  particular  label  ranges.  This 
scheme  was  quickly  discarded  due  to  its  inflexibility.  If  a  gateway 
along  a  fixed  route  had  gone  down,  packets  would  still  have  been 
sent  to  it,  and  lost,  even  though  an  alternate  path  might  huve 
existed. 

5.2.3.  Chosen  Solution 

It  soon  became  obvious  that  the  existing  routing  protocol  could 
also  be  used  to  propagate  the  label  range  of  each  reachable  net¬ 
work.  The  routing  daemon  will  initially  know  the  ranges  of  all 
directly  attached  networks  and  these  ranges  can  easily  be  distri¬ 
buted  to  all  daemons  in  un  internet. 

Each  time  a  router  passes  along  a  route  that  it  has  learned,  it  incre¬ 
ments  the  hop  count  metric,  reflecting  the  extra  network  that  must 
be  traversed.  The  same  idea  can  be  used  with  label  ranges.  In  this 
case  a  new  metric  is  created,  which  Sun  shall  call  the  “route  label 
range".  This  range  is  the  most  restrictive  range  of  all  networks 
along  the  path;  that  is,  the  intersection  of  each  network’s  label 
range. 

The  routing  protocol  must  save  ull  routes  to  a  given  network  which 
have  different  route  label  ranges.  When  a  packet  must  be  for¬ 
warded  through  a  gateway,  its  label  is  compared  to  the  ranges  of 
all  possible  routes.  In  this  way  an  appropriate  gateway  cun  be 
selected  for  the  next  leg. 
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Figure  10:  The  Routing  Table  for  Host  B  in  Figure  9. 


This  scheme  is  very  flexible.  Each  gateway  is  free  to  make  new 
routing  decisions,  reflecting  local  conditions  near  that  gateway. 
Therefore,  a  poor  choice  of  initial  gateway  need  not  mean  that  the 
packet  will  be  discarded. 

The  new  routing  protocol  will  be  backward  compatible  with  exist¬ 
ing  Sun  routers,  so  that  coexistence  with  Foreign  Hosts  is  possible. 
When  routing  information  is  received  from  such  a  host  the  single¬ 
label  label  of  that  host  can  be  attached  to  all  paths  through  it, 
reflecting  the  restriction  placed  on  the  use  of  Foreign  Hosts  as 
gateways. 

6.  Conformance  to  Proposed  Security  Additions  to  IP 

As  mentioned  above.  Sun  is  using  an  IP  Option  to  include  security 
label  information  in  the  IP  packet  heuder.  There  is  a  draft  under¬ 
way  for  revised  Internet  Protocol  Security  Options;  however,  these 
options  are  not  appropriate  for  Sun’s  use.  Both  of  the  standard 
security  option  specifications  ([DoD831  and  IRFC88 1)  use  part  of 
the  option  to  indicate  an  accrediting  authority  and  use  the  rest  of 
the  option  as  defined  by  this  specified  authority.  Since  the  Sun 
label  option  would  need  to  be  usable  by  any  or  all  of  die  authori¬ 
ties,  it  is  not  appropriate  to  chose  a  particular  authority’s 
configuration  for  the  label. 
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Sun  plans  to  provide  translation  functions  which  will  allow  map¬ 
ping  between  the  internal  label  and  the  security  information  for 
each  authority.  Any  mapping  which  is  specified  in  an  RFP  can  be 
supported.  Note  that  the  label  option  is  only  used  internally  in  the 
Secure  SunOS  system.  The  translation  would  only  need  to  occur 
for  communication  with  external  systems. 


7.  Summary 

Sun  Microsystems  is  committed  to  excellence  and  standards.  In 
this  particular  project,  the  standards  involved  are  POSIX,  the 
ARPAnet  low-level  protocols,  and  most  importantly  the  Depart¬ 
ment  of  Defense  Trusted  Computer  System  Evaluation  Criteria 
[DoD85j.  In  many  cases  at  the  start  of  the  project,  these  standards 
seemed  at  odds  with  euch  other.  In  particular,  TCP  and  IP  were 
not  designed  with  security  in  mind.  Thus,  backwards  compatibil¬ 
ity  and  emerging  technology  became  serious  design  problems. 
With  considerable  effort  and  help  front  a  number  of  areas  within 
Sun,  the  Secure  SunOS  system  has  come  up  with  a  unique  solution 
which  fits  into  existing  environments. 
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Abstract 

Local  area  networks  (LANs)  arc  being  widely  used  for  a  large 
number  of  applications.  Howovor,  LANs  are  vulnerable  to  scvural 
security  threats  including  wiretapping,  masquerading,  modification 
of  data,  and  denial  of  service. 

This  paper  desrribes  Ethernet  Enhanced-Security  System,  a 
system  that  can  help  provide  security  for  an  Ethernet  or  extended 
Ethernet.  The  Ethernet  is  secured  at  the  Data  Link  Layer  and  the 
system  is  transparent  to  network  software  operating  at  a  higher 
layer.  The  system  consists  of  Digital  Ethernet  Secure  Network 
Controllers  and  VAX  Key  Distribution  Center  software.  A  DESNC 
controller  is  an  encryption  dovico  that  provides  node 
authentication  and  privacy  and  integrity  of  Ethernet  frames.  The 
KDC  software  manages  the  DESNC  controllers  on  an  Ethernet  or 
extended  Ethernet  and  onforco  a  LAN  access  control  policy.  If  tile 
access  control  policy  allows,  nodes  protected  by  controllers  can 
communicate  with  nodes  not  protected  by  controllers. 

LAN  Security  Threats 

Ethornot[l|  and  other  Local  Area  Network  (LAN)  technologies 
provide  the  means  to  interconnect  computer  systems  conveniently, 
LANs  are  used  in  many  environments,  but  there  are  many 
situations  where  they  cannot  be  used  because  or  the  requirement 
for  a  higher  level  of  security  than  that  provided  by  any 
commercially  available  LAN.  Some  LAN  security  threats  are: 

Wiretapping:  The  most  obvious  LAN  security  problem  is 
wiretapping.  This  security  pioblem  is  most  serious  for  broadcast 
LANs  where  every  node  connected  to  the  LAN  is  able  to  read  all  of 
tile  data  that  is  transmitted  on  the  LAN.  It  is  easy  to  attach  a 
LAN  traflic  monitor  to  any  broadcast  LAN  and  read  all  traffic  on 
the  LAN.  In  addition,  some  LAN  architectures  define  a  mode  or 
operation,  typically  referred  to  as  'promiscuous  mode',  which 
allows  a  node  to  receive  all  data  frames  transmitted  on  the  LAN 
regardless  of  the  destination  address  of  the  frame.  LAN  adapters 
that  implement  this  feature  make  eavesdropping  easy  to 
accomplish  and  difficult  to  detect. 

The  wiretap  threat  can  be  addressed  either  by  physical  security 
for  the  LAN  or  through  encryption.  However,  physical  security 
requires  close  monitoring  of  the  LAN  components,  including  all 
cables  inside  and  between  buildings,  and  cannot  protect  against 
unauthorised  monitoring  of  the  LAN  by  nodes  authorized  to  use 
the  LAN.  For  Ethernet  and  other  broadcast  LAN  technologies, 
standard  Data  Link  Layer  encryption  techniques  cannot  be  used  to 
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prevent  wiretapping  because  a  large  number  of  nodes  all 
communicate  over  a  common  medium. 

Masquaradlng;  LANs  are  also  vulnerable  to  masquerading 
attacks.  It  is  easy  for  an  unauthorized  node  connected  to  a  LAN, 
or  for  a  node  that  is  authorized  to  use  a  LAN  but  which  is 
untrusted  or  compromised,  Lo  masquerade  ns  another  node.  Many 
LAN  adapters  allow  the  source  address  of  LAN  frames  to  be 
selected  or  changed  by  the  node,  making  it  easy  for  a  node  to 
perform  a  masquerading  attack. 

Protection  against  masquerading  attacks  requires  the 
authentication  of  frames  transmitted  on  the  LAN.  Physical  security 
on  a  LAN  would  only  protect  ngainsL  masquerading  by  intruders, 
not  by  nodes  that  are  allowed  some  access  to  the  LAN. 

Modification:  Another  possible  attack  on  a  LAN  is  the 
modification  of  data.  Nodes  may  modify  frames  sent  on  the  LAN 
and  transmit  the  modified  versions.  This  attack  can  be  used  lo 
compromise  communication  between  trusted  nodes,  even  when 
some  level  of  authentication  is  used. 

Protection  against  modification  attacks  requires  integrity  checks 
on  frames  transmitted  on  tho  LAN.  These  checks  should  bo 
cryptographic  functions  of  the  frame,  or  cryptographically 
protected.  As  with  masquerading,  physical  security  would  only 
protect  against  against  attacks  made  by  nodes  not  authorized  lo 
use  the  LAN, 

Denial  of  Service:  Tho  operation  of  a  LAN  can  be  prevented  or 
slowed  with  denial  of  service  attacks.  Denial  of  service  includes 
such  attacks  as  physical  damage  to  LAN  components  (e.g,,  cutting 
the  cable),  disrupting  communication  by  not  using  the  correct  LAN 
protocol  (e.g.,  sending  the  wrong  signals,  or  sending  signals  at  the 
wrong  time),  or  overloading  the  LAN  by  flooding  it  with  traffic. 

Protection  against  denial  of  service  attacke  requires  physical 
security  for  the  LAN  components  to  prevent  physical  damage.  It  ie 
also  necessary  lo  use  LAN  adapters  that  are  trusted  to  follow  the 
correct  LAN  standard,  and  to  monitor  the  LAN  for  attempts  to 
disrupt  communication  by  flooding  the  LAN  with  Irafik. 

LAN  Security  Strategies 

While  all  LAN  technologies  have  these  vulnerabilities,  and 
especially  all  broadcast  LANs,  Digital's  LAN  strategy  is  centered 
around  Ethernet.  For  this  reason,  Digital  has  developed  the 
Ethernet  Enhanced-Security  System  consisting  of  Digital  Ethernet 
Secure  Network  Controller  hardware  and  VAX  Key  Distribution 
Center  software. 

There  are  three  security  strategies  that  could  be  used  to  protect 
a  LAN: 
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i  Ethernet 


Figure  l:  Simple  Network  Diagram 

Physical  Security:  Maintaining  tight  controls  on  access  to  the 
LAN  communication  medium  docs  prevent  access  by  unauthorized 
nodes,  but  the  security  becomes  hard  to  maintain  in  extended  LAN 
environments  and  it  does  nothing  to  prevent  wiretapping, 
masquerading,  modification,  or  denial  of  service  attacks  by 
authorized  users  of  the  LAN. 

Separate  LANs;  Partitioning  a  LAN  into  physically  separate 
LANs  for  different  user  groups  do  us  prevent  attacks  from  nodes 
assigned  to  other  security  levels,  hut  it  does  not  prevent  attacks 
from  nodes  with  a  security  level  and  it  places  limits  on 
communication  that  are  not  practical  in  tunny  environments. 

Encryption!  A  welbdoaigned  Kcheine  For  dist  ributing  keys  and 
encrypting  communication  or  a  LAN  can  prevent  wiretapping, 
masquerading,  ami  modification  attacks,  and  allow  a  flexible  LAN 
access  cont  rol  policy  to  be  implemented.  Unless  all  equipment  on 
the  LAN  is  designed  to  encrypt  and  decrypt  fi nines,  additional 
hardware  is  required  to  implement  I  ho  encryption.  It  is  also 
necessary  to  have  u  facility  for  generating  and  distributing  the 
encryption  keys  necessary  for  encrypting  th.u  frames. 

Approach 

Of  t  he  strategies  mentioned  above,  encryption  is  the  only 
alternative  that  authenticates  nodes  connected  to  the  LAN  and 
allows  a  flexible  access  control  policy  to  be  implemented,  for  I  his 
reason,  encryption  is  the  only  reasonable  approach  to  addressing 
most  LAN  security  ilireats. 

The  DKSNU  controller  is  a  hardware  device  that  nits  between  a 
node  .and  the  Ethernet  and  encrypts  flames  transmitted  by  the 
nolle  and  decrypts  frames  received  by  the  node  (see  figure  I).  Thu 
frames  are  encrypted  using  the  DES  encryption  algorithm.  A 
manipulation  v‘"leclion  code  (MDCJJ  is  added  to  the  frames  when 
they  are  encrypted  and  verified  when  they  are  decrypted.  The 
caul  rollers  also  verify  the  source  address  on  each  frame  transmitted 
by  the  node.  UocuufM  of  the  frame  processing  required,  controllers 
are  store-and-forward  devices. 

Controllers  have  one  port  that  is  connected  to  the  LAN  and  four 
ports  that  are  connected  to  nodes.  The  four  node  ports  ori  a 
controller  are  separate  security  domains.  A  node  attached  to  one 
node  port  cannot  read  frames  transmitted  to  a  node  on  another 
node  port.  Multiple  nodes  can  be  connected  to  one  node  port.  The 
four  ports  can  support  up  to  20  nodes  in  any  combination. 

The  interface  used  by  the  ports  is  standard  Ethernet  (or 
IEEE  802)  format  frames.  DESNC  controllers  are  designed  Lo 
interoperate  with  any  equipment  that  uses  the  Ethernet  or 
IEEE  802  standards.  The  controllers  operate  at  the  Data  Link 
Layer,  and  are  transparent  to  any  network  software  operating  at  a 


higher  layer.  For  example,  DECnet  or  TCP/ IF  software  does  not 
require  modification  to  be  used  in  a  LAN  protected  by  DESNC 
controllers. 

The  controllers  are  managed  by  VAX  KDC  software  running  on 
specially  designated  KDC  nodes  on  the  Ethernet,  These  KDG 
nodes  must  be  running  the  VAX/VMS  operating  system.  KDC 
nodes  do  not  perform  all  parts  of  the  KDC  operations,  they  require 
Lho  support  of  an  attached  DESNC  controller.  These  KDC 
controllers  are  physically  the  same  as  other  DESNC  controllers, 
but  they  store  more  information  and  perform  additional  functions. 

Under  normal  operating  conditions,  a  node  protected  by  a 
controller  can  only  communicate  with  other  nodes  when  the 
communication  is  approved  by  a  KDC.  When  a  node  attempts  to 
communicate,  the  controller  that  receives  the  first  frame  requests 
an  ‘association’  from  a  KDC  node  for  the  pair  of  nodes  that  want 
to  communicate.  Associations  always  allow  communication  in  two 
directions. 

Up  to  five  KDC  nodes  are  allowed  on  an  Ethernet  or  extended 
Ethernet.  Multiple  KDCs  increase  the  reliability  and  availability  of 
the  LAN  because  they  increase  the  probability  that  a  controller 
will  be  able  to  communicate  with  a  KDC  when  the  controller  wants 
to  set-up  an  association. 

If  an  extended  Ethernet  is  used,  spreading  the  KDCs  over  the 
extended  LAN  also  improves  availability.  IT  a  problem  causes  the 
extended  LAN  to  be  segmented,  it  is  more  likely  that  each 
controller  will  be  able  to  communicate  with  some  KDC  if  Lho  KDC 
nodes  are  distributed  across  the  extended  LAN. 

Protection  AgJthist  LAN  Security  Throats 

The  Ethernet  Enhanccd-Securiiy  System  protects  against 
masquerading,  wiretapping,  and  modification  attacks,  and,  to  a 
limited  extent,  some  denial  of  service  attacks. 

Masquerading:  Nodes  protected  by  controllers  are  not  allowed 
to  masquerade  as  other  nodes  because  the  controllers  check  the 
source  address  of  transmitted  frames.  Because  ronuimnicalion 
must  be  approved  by  a  KDC,  controllers  will  deled  masquerading 
attempts  by  nodes  not  protected  by  a  controller. 

If  multiple  nodes  are  attached  to  one  node  port  on  a  controller, 
the  controller  will  not  be  able  to  distinguish  between  the  nodes  nor 
br  able  to  delect  attempts  by  one  of  the  nodes  to  masquerade  as 
another,  l  or  this  reason  it  is  recommended  that  only  one  node  he 
attached  to  each  node  port,  but  mutually  trusted  nudes  can  be 
chained  on  one  port. 

W Irotflpplirg;  Controllers  ensure  the  privacy  of  communication 
between  any  two  nodes  attached  to  DESNC  controllers  by 
encrypting  the  Ethernet  frames  sent  between  the  nodes. 

No  attempt  is  made  to  hide  the  length  of  encrypted  Ethernet 
frames.  Because  the  original  header  of  the  Ethernet  frame  is  useful 
for  LAN  management,  it  is  sent  in  unencrypted  form  on  the 
Ethernet.  However,  the  header  is  protected  against  modification  by 
placing  another  copy  of  the  header  in  the  encrypted  portion  or  the 
message. 

Modification;  The  manipulation  detection  code  that  controllers 
add  to  Ethernet  frames  when  the  frames  are  encrypted  allows  the 
controllers  to  deLect  attempts  to  modify  an  Ethernet  frame.  In 
addition  to  the  unencrypted  copy  of  the  header  of  each  Ethernet 
frame,  the  header  of  each  Ethernet  frame  is  also  included  in  the 
encrypted  portion  of  the  frame  exchanged  between  controllers,  so 
the  header  is  protected  by  t  he  manipulation  detection  code. 

The  MD(J  is  a  lfl-bil  OKC,  but  the  MDO  value  is  transit:  Lied  in 
the  encrypted  portion  ol  the  Ethernet  frarnun.  Because  the 
information  being  protected  and  the  MDC  value  are  both 
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encrypted  with  UES,  deterministic  changes  cannot  be  made  to  the 
encrypted  data  or  the  MDC.  This  means  that  there  is  a  low 
probability  that  an  intruder  will  be  able  to  modify  an  encrypted 
frame  without  the  modification  being  delected  when  the  frame  is 
decrypted  and  the  MUG  field  checked  (i.c.,  a  huge  number  of 
attempts  will  be  required  before  one  frame  is  successfully  modified). 

Denial  of  Service?:  D15SNC  controllers  are  not  intended  to 
provide  protection  against  denial  of  service  attacks.  However, 
nodes  protected  by  controllers  are  isolated  from  tho  LAN  and  so 
the  clioct  of  any  attempts  by  these  nodes  t.o  jam  the  Ethernet  or 
disrupt  the  Ethernet  by  not  obeying  the  Ethernet  standard  will  not 
be  allowed  to  ailed  nodes  other  than  the  nodes  protected  by  that 
particular  controller. 

Access  Control  Policy 

The  network  security  manager  for  an  Ethernet  secured  by 
controllers  can  determine  which  pairs  of  nodes  are  allowed  to 
communicate.  The  ability  to  communicate  is  determined  by  an 
access  class  range  for  the  nodes  and  by  the  ability  of  a  node  to 
communicate  unencrypted. 

The  network  assigns  un  access  class  range  to  each  node  on  tile 
LAN.  The  access  class  ranges  arc  from  a  Bell  and  LaPadula|2|/ 
Bibn[3]  secrecy  unci  integrity  lattice,  with  250  secrecy  and  integrity 
levels  and  64  secrecy  and  integrity  categories. 

Trusted  nodes  may  be  assigned  a  range  of  access  classes,  but 
untrusled  nodes  are  assigned  a  single  access  class.  Two  nodes  are 
only  allowed  lu  communicate  if  they  operate  at  the  same  access 
class,  or  if  the  access  class  ranges  for  the  nodes  overlap  in  i*.t  least 
one  common  access  class. 

The  access  class  ranges  alone  determine  if  two  nodes  protected 
by  controllers  are  allowed  to  communicate.  However,  if  only  one 
node  is  protected  by  a  UESNC  controller  then  an  additional  factor 
is  considered:  The  network  security  manager  can  specify  which 
nodes  are  allowed  to  communicate  with  nodes  that  are  not 
protected  by  controllers  and  which  nodes  call  only  communicate 
when  tho  transmitted  frames  will  be  encrypted. 

Bypass  Opuraln > 1 l 

For  normal  operation,  controllers  must  be  able  to  communicate 
with  at  least  one  KUG.  If  a  controller  cannot  communicate  with 
any  KDCs,  it  will  not  be  able  to  determine  which  pairs  of  nodes 
should  he  allowed  to  communicate. 

To  handle  situations  where  the  KDCs  on  an  Ethernet  are  not 
operational,  a  UESNC  controller  can  be  placed  in  Bypass  state. 
This  is  done  by  pressing  a  Bypass  pushbutton  on  the  front  pane!  of 
each  controller. 

When  the  Bypass  pushbutton  is  pressed,  a  controller  will  enter 
Bypass  state  if  it  cannot  communicate  wiih  any  KDCs.  Nodes  are 
only  allowed  to  send  and  receive  frames  when  the  controller  is  in 
Bypass  slate  if  the  controller  has  previously  been  informed  by  a 
KDC  that  the  nude  is  allowed  to  communicate  in  Bypass  state. 
When  a  controller  is  in  Bypass  state  it  will  not.  encrypt  any 
Ethernet  frames.  Even  in  Bypass  state,  the  controllers  check  the 
source  address  of  frames  transmitted  by  a  node  and  only  send  a 
node  the  Et  hernet  frames  that  are  addressed  to  tho  node. 

The  network  security  manager  may  choose  which  nodes  arc 
allowed  to  communicate  when  the  controller  that  protects  them  is 
in  Bypass  st.uto.  The  network  security  manager  should  determine, 
for  each  node,  if  it  is  more  important  for  tho  node  to  be  able  to 
communicate  whenever  possible  (allow  communication  when  the 
controller  is  in  Bypass),  or  to  be  secure  whenever  possible  (disallow 
communication  when  the  controller  is  in  Bypusn). 


Multicast  Frames 

Because  frames  sent  to  a  multicast  (or  bioadcnsl)  destination 
address  are  intended  to  be  read  by  many,  if  not  all,  of  the  nodes  on 
a  LAN,  it  is  not  possible  to  encrypt,  multicast  frames  in  the  same 
manner  as  other  Ethernet  trallic.  UESNC  controllers  do  not 
encrypt  multicast  frames. 

Controllers  pass  multicast  frames  without  any  modifications,  hut 
they  allow,  at  the  request  of  a  KDC,  a  node  to  be  prevented  from 
transmitting  multicast  frames.  In  some  network  environments,  it.  is 
necessary  to  allow  all  nodes  to  transmit,  multicast  frames  because 
many  network  protocols  depend  on  multicast  frames  for  correct 
operation. 

Because  UESNC  controllers  are  designed  l-o  work  un  LANs 
where  only  some  of  the  traffic  is  encrypted,  it.  would  not  he 
possible  to  simply  encrypt  multicast  messages  with  a  common 
Ethernet-wide  key — it  would  be  necessary  to  send  the  messages  in 
unencrypted  form  as  well  ns  encrypted  form  to  reach  the  nodes 
that  were  not  connected  to  UESNC  controllers. 

Trust 

With  any  security  system,  it  i«  important  to  know  which 
components  must  he  trusted,  and  the  degree  of  trust  required. 
Ethernet  Security  •Enhanced  System  was  designed  to  limit,  the 
degree  that  an  individual  UESNC  controller  needs  to  be  trusted. 

The  compromise  of  a  UESNC  controller  may  compromise  the 
tardea  protected  by  the  controller,  but  will  not  compromise  any 
oilier  controllers  or  nodes  on  the  LAN.  This  na  ans  that  a 
controller  must  he  protected  as  well  as  any  of  the  nodes  protected 
by  the  controller. 

If  multiple  nodes  are  connected  to  the  same  node  port  of  a 
controller,  the  nodes  can  masquerade  as  each  other.  'Phis  moans 
that  the  multiple  nodes  must,  be  mutually  trusting.  If  this  is  level 
of  trust  is  not  appropriate,  a  site  can  use  UESNC  controllers  with 
only  one  node  attached  to  each  of  the  four  node  purls. 

If  a  KDC  node  or  the  controller  that  supports  a  KDC  node  is 
compromised,  the  security  of  the  LAN  tan  be  compromised.  'Phis 
means  that  KDC  nodes  and  KDC  controllers  must  be  protected  as 
well  as  any  node  on  the  LAN  While  KDC  nodes  can  be  used  for 
multiple  purposes,  the  security  of  the  network  is  improved  if  the 
KDC  nodes  are  limited  to  network  management  functions  and 
access  to  the*  nodes  is  limited  to  trusted  individuals. 

Ethernet  Enhanced- Security  System 
Architecture 

Encryption  Keys 

Messages  exchanged  among  DliSNC  controllers  and  KDCs  arc 
encrypted  using  the  Data  Encryption  Standard  (DIOS)  encryption 
ulguritlmi['!,,r>j.  The  messages  arc  encrypted  using  the  Cipher  block 
Chaining  mode  of  l)KS. 

Several  different  types  of  DIOS  encryption  keys  are  used  by 
controllers  and  tho  KDC  software 

KDC  Master'  Keys  This  key  is  used  to  encrypt  keys  that  are 
stored  on  KDC  nodes.  Tills  key  is  only  known  by  the  network 
security  manager  and  the  KDC  controllers 

Key  Generation  Keys  If  keys  are  generated,  this  key  is  used  as 
part  of  the  process  Lo  generate  the  keys.  This  key  is  only 
known  to  the  network  security  manager  and  the  KDC 
controllers. 
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Initialization  Key:  Initialization  keys  are  used  to  initialize  a 
controller.  These  keys  arc  used  to  distribute  the  master  and 
service  keys  for  a  controller,  and  aro  then  never  used  again, 
Those  keys  arc  only  known  by  the  network  security  manager, 
the  controller  initialized  with  the  key,  and  the  KDC  that 
initializes  the  controller. 

Master  Key  and  Service  Key!  These  encryption  keys  are  ueed 
to  communicate  between  controllers  and  KDCs.  A  different  set 
of  keys  is  used  for  each  controller.  The  key  for  a  controller  is 
only  known  by  the  controller  and  the  KDCs,  and  they  are  only 
stored  in  encrypted  form  on  KDC  nodes.  These  keys  are  never 
handled  by  any  person  in  unencrypted  form. 

Association  Key:  These  keys  are  used  to  encrypt  communication 
between  nodes  protected  by  controllers.  A  different  association 
key  is  used  for  each  pair  of  nodes  that  communicate. 
Association  keys  are  distributed  by  KDCs  when  controllers 
request  associations. 

KDC  controllers  will  generate  encryption  keys  as  needed  by  the 
KDC  nodes,  or  the  network  security  manager  can  have  the  KDC 
nodes  acquire  the  keys  that  they  need  frum  a  user-supplied  source. 
A  small  amount  of  user  programming  is  required  to  use  a 
user-supplied  key  source,  as  well  as  a  large  supply  of  keys. 

Initializing;  Controllers 

Before  a  controller  can  operate,  it  must  be  initialized.  'I'o  initialize 
a  controller,  the  following  stops  are  required: 

•  The  network  security  manager  enters  information  about  the 
controller  and  the  nodes  protected  by  the  controller  into  a 
KDC  node.  This  information  includes  the  addresses  of  the 
controller  and  the  nodes  and  the  access  control  policy  for  the 
nodes. 

•  On  the  request  of  the  network  security  manager,  the  KDC 
node  selects  an  initialization  key  for  the  controller.  The  key  is 
cither  generated  or  taken  from  a  supplied  key  source. 

•  The  network  security  manager  enters  the  initialization  key  in 
the  controller. 

•  The  controller  communicates  with  the  KDC  and  the  master 
encryption  key  for  the  controller  is  distributed.  This  message 
is  encrypted  with  the  initialization  key  that  was  entered  into 
the  controller.  The  initialization  key  is  not  used  after  this  step. 

«  The  controller  communicates  with  the  KDC  and  the  KDC 
distributes  the  information  that  the  controller  needs  to 
operate.  This  information  includes: 

-  The  duration  of  associations  between  nodes. 

-  The  name  of  the  firmware  that  the  controller  should  be 
using,  and  a  cryptographic  checksum  for  the  firmware 
image. 

-  The  addresses  of  the  key  distribution  centers  on  the  LAN. 

--  The  addresses  of  the  nodes  supported  by  the  controller. 

-  Information  about  the  supported  nodes.  This  includes 
such  information  as  whether  eacli  node  is  allowed  to 
communicate  when  the  controller  is  in  Bypass  state. 

-  A  list  of  the  events  that  the  controller  should  audit. 

After  these  steps,  the  controller  is  operational.  The  controller 
can  now  communicate  with  any  KDC  on  the  LAN.  Once  a 
controller  is  initialized  it  is  not  necessary  to  manually  enter  any 
additional  information.  If  the  distributed  information  needs  to  be 


changed,  the  changes  can  be  done  remotely  trom  any  KDC, 

DESNC  controllers  retain  the  distributed  information  during 
power-ofl  or  power  interruptions  for  a  minimum  of  72  hours. 

Operational  controllers  will  request  associations  from  KDC  node 
as  necessary,  and  encrypt  and  decrypt  Ethernet  frames  sent  by 
nodes. 

Downline  Loading  Controllers 

The  operational  firmware  images  used  by  DESNC  controllers  is 
downline  loaded  ovor  the  Ethernet  using  the  same  mechanism  used 
by  other  DEC  products.  This  allows  the  controllers  to  be  downlino 
loaded  by  the  same  downline  load  servers  that  load  other  products 
on  the  Ethernet.  The  integrity  of  the  images  (and  the  security  of 
the  LAN)  is  protected  in  the  following  maimer: 

1.  When  a  new  firmware  image  is  installed  on  the  network,  a 
KDC  generates  an  encryption  key  and  a  cryptographic 
checksum  for  the  image.  The  KDC  generates  a  different  key 
and  checksum  for  each  controller  on  the  Ethernet. 

2.  When  a  controller  is  initialized,  the  KDC  distributes  the  name 
of  the  firmware  image  and  the  appropriate  checksum 
information  to  each  controller.  If  the  image  changes  after  a 
controller  is  initialized,  any  KDC  may  distribute  the  new 
image  name  and  checksum  information  to  the  controller. 

3.  When  a  controller  needs  to  be  downline  loaded,  it  requests  the 
appropriate  image.  After  the  image  is  received  from  a 
downline  load  server,  the  controller  calculates  the  checksum 
for  the  image  and  compares  the  value  against  the  stored  value. 
If  the  received  image  does  not  have  the  correct  checksum  then 
that  image  is  ignored  and  a  new  image  is  requested. 

4.  The  DESNC  controller  stores  the  checksum  in  memory  that  is 
preserved  over  power  failures,  Because  of  this  is  is  not 
necessary  to  distribute  checksum  information  to  all  controllers 
after  a  power  failure 

Associations 

When  two  nodes  try  to  communicate  by  exchanging  Ethernet 
frames  over  the  LAN,  controllers  will  not  allow  the  communication 
unless  the  'association'  is  allowed  by  a  KDC,  These  associations  are 
granted  upon  demand  by  KDCs. 

There  are  three  different  types  of  associations: 

•  Associations  between  two  nodes  protected  by  different 
controllers.  Frames  sent  under  these  associations  are 
encrypted  while  they  arc  on  the  Ethernet. 

•  Associations  between  two  nodes  protected  by  the  same 
controller.  Frames  sent  under  these  associations  are  never  sent 
on  the  Ethernet  so  there  is  no  need  for  them  to  be  encrypted. 
The  controller  only  sends  the  frame  to  til.-  node  port  where 
the  destination  node  is  attached. 

•  Associations  between  a  node  protected  by  controllers  and  a 
node  not  protected  by  a  controller.  Frames  sent  under  these 
associations  are  not  encrypted  (because  there  is  no  second 
controller  to  decrypt  the  frame),  but  communication  is  not 
allowed  unless  approved  by  a  KDC. 

Examples  of  these  three  types  of  associations  are  shown  in  figure  2 
When  two  nodes  communicate  directly  (without  any  intervening 
DESNC  controllers),  controllers  and  KDCs  are  not  involved  in  the 
communication. 
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Figure  2:  Typed  of  Associations 


Association  Sot-Ujn  'Dio  protocol  exchange  used  between 
DftSN(J  ctintfnllers  ami  KIK's  l<>  set* up  associations  is  similar  to 
tlic  protocol  used  in  Vuydork  and  Kt:nl[(>|.  Here  is  an  example  of 
I io\v  mi  association  would  be  established  between  two  nodes  that 
arc  both  connected  to  DKSNC  controllers. 

Consider  the  LAN  shown  in  figure  2.  Setting  up  an  association 
between  node  7  and  node  8  (with  node  1  acting  as  the  KIX,*  node) 
involves  the  following  .teps: 

1.  Node  7  sends  an  Klhrriiel  frame  to  node  8, 

2.  Controller  (*  receives  the  Klhernel  frame  and  verifies  the 
source  address  of  the  frame. 

!}.  Controller  C  requests  an  association  from  the  KDC  (node  -1). 

■I.  'Hie  KDC  checks  the  across  control  policy  and  determines  that 
nodes  7  rind  H  are  allowed  Lo  communicate  and  sends  an 
Association  Open  message  to  controller  <’  The  Association 
Open  message  is  encrypted  with  the  master  key  of 
controller  (‘  The  message  contains  uti  association  key,  either 
generated  by  the  KDC  controller  or  taken  from  supplied  keys. 

r»  Controller  C  sends  an  Association  Forward  message  to 
controller  I).  The  Association  Forward  message  is  encrypted 
with  the  master  key  of  controller  U  and  was  generated  by  the 
KDC  and  included  in  the  Association  Open  message  sent  to 
control le r  CL 

b.  C'oid  follfis  C  and  I?  communicate  ami  determine  that  they 
share  a  common  association  key. 

7.  Controller  C  crcypis  the  message  sent  in  step  1  with  the 
association  k  -y  a.id  sends  the  encrypted  frame  to  controller  D. 

8.  Controller  D  receives  the  encrypted  Triune,  decrypts  the  frame, 
checks  the  manipulation  detection  code,  and  transmits  the 
frame  to  node  8. 

Once  the  association  is  established,  no  further  interaction  with 
the  KDC  is  required  and  all  communication  between  nodes  7  and  8 
is  encrypted  with  the  association  key  until  the  association  expires. 
At  that  point,  another  association  is  requested  by  the  controllers. 
'Hu*  duration  of  associations  is  determined  by  the  network  security 
manager.  If  an  association  is  ucLive  and  approaching  expiration, 


the  controller  f.luil  originally  requested  the  association 
(controller  C  in  this  example)  will  request  another  association 
before  l lie  first  association  expires. 


Encrypted  Frame*  Format 


When  Ethernet  frames  sent  by  nodes  an*  encrypted  by  DKSNCJ 
controllers,  the  frames  are  protected  in  several  different  ways: 

•  Tlu>  frames  are  encrypted  to  prevent  disclosure  of  the 
contents,  and  also  to  prevent  predictable  modification. 


•  Sequence  numbers  are  included  in  the  encrypted  portion  of  the 
frame  Lo  detect,  replay  and  reflection  (sending  frames  back  to 
tile  sender  with  the  source  and  destination  addresses  swapped). 

•  A  Manipulation  Detection  Code  (MDC)  is  appended  to  the 
frame  before  if.  is  encrypted.  This  field  is  checked  when  the 
encrypted  frame  is  decrypted  to  determine  if  the  frame  was 
modified. 


Several  other  changes  are  made  to  the  format  oT  the  frames  when 
they  are  encrypted: 


•  A  new  IDL'D  802  header  is  added  lo  the  start  of  the  frame. 
The  protocol  identifier  in  the  frame  header  allows  DIOSNC 
controllers  to  determine  which  of  the  frames  it  receives  are 
encrypted. 


•  A  message  type  is  placed  after  the  header  to  distinguish 
encrypted  framoH  sent  by  nodes  from  other  encrypted  control 
messages.  A  copy  of  the  message  type  is  placer!  in  t lie 
encrypted  portion  of  the  frame  to  allow  changes  to  the 
message  type  to  be  detected. 


•  An  encryption  idenLiher  is  also  added  to  allow  the  controller  to 
determine  which  encryption  key  should  be  used  to  decrypt,  the 
frame.  ('Phis  is  just  a  performance  optimization,  if  would  be 
possible  for  the  controller  to  determine  the  appropriate  key 
from  the  frame  addresses  and  the  message  type.) 


•  Two  copies  of  the  original  frame  header  (other  than  the 
Ethernet  addresses)  are  placed  in  the  frame.  One  copy  is 
unencrypted  and  can  be  used  by  LAN  management  tools,  the 
other  copy  is  encrypted  so  that  any  attempts  to  modify  the 
header  will  be  detected. 


223 


Destination  Address 
Source  Address 

ll^ir^2T?cadcr 
Message  Type 
Knc ry ption  Identifier 
Original  Header 
Sequence  Number  * 

Message  Type  Copy  * 

Original  f leader  * 

Original  Data  Kidd  * 

Padding  * 

Tine _ '  * 

Kthernet  KCS  + 

*  marks  the  encrypted  Holds. 

Figure  IP  Kncry plt’tl  Fmine  Formal 

•  The  encrypted  portion  of  the  framo  is  padded  to  a  multiple  of 
the  DKS  block  size  to  allow  the  frame  lo  be  encrypted  using 
CBC  mode.  'The*  pudding  is  removed  when  the  framo  is 
decrypted. 

•  The  correct  Kthernet  Frame  Cheek  Sequence  (FCS)  is 
appended  to  the  newly  created  frame.  The  original  FCS  will 
be  used  when  the  frame  is  transmitted  to  the  destination  node. 

The  format  of  an  encrypted  frame  is  shown  in  figure  If. 
lOverythiug  from  the  sequence  number  to  the  MDC  is  encrypted. 

Fragmentation:  Ifecausc  additional  fields  are  added  to  frames 
by  DKSNC  controllers,  frames  that  are  close  lo  the  maximum 
length  will  be  extended  beyond  the  maximum  allowed  length  for 
Kthernet  frames.  To  handle  this  situation,  DKSNC  controllers 
‘fragment*  long  Ktheniol  frames  and  transmit  then  in  two 
encrypted  Kthernet  frames. 

This  fragmentation  and  reassembly  affects  the  performance  of 
coiimumicatioii.  but  the  fragmentation  is  handled  by  controllers 
and  transparent  to  the  nodes  involved.  Kthernet.  performance  can 
be  improved  for  a  node  :f  the  network  software  on  the  node  is 
modified  to  always  send  frames  that  are  shorter  than  1*181)  bytes. 

AmUtjijH 

Controllers  and  KDCs  generate  security  related  audit  events. 
Controllers  and  KIX.’r  always  count  significant  events  as  they 
occur,  and  detailed  information  about  some  events  is  recorded  by 
the  KDC  server.  The  stored  events  can  bo  displayed  by  the 
network  security  manager. 

The  level  of  auditing  can  be  selected  by  (he  network  security 
manager  by  choosing  which  controllers  ami  K DCs  record  which 
classes  of  events.  There  are  18  auditable:  events  including: 

•  Controller  status  messages  and  state  changes. 

•  Association  requests. 

•  II ejected  associations  requests. 

•  Invalid  frame  addresses,  sequence  numbers,  or  MDCs. 

The  network  security  manager  can  select  which  events  are 
included  in  audit  reports,  und  it  is  possible  to  have  the  KDC  server 
send  selected  classes  of  events  to  a  physical  alarm  device  (c.g.,  a 
terminal  or  a  printer) 


Software  Design 

The  VAX  KDC  software  is  a  layered  product  that  runs  under  the 
VAX/ VMS  operating  system,  There  are  two  parts  to  the 
VAX  KDC/  software: 

•  A  KDC/  Server  that  runs  continuously.  This  program  responds 
to  association  requests  for  the  controllers  on  the  I/AN  ami 
records  audit  events  generated  by  controllers  and  the  KDC 
software. 

•  A  KDC  User  Interface  that  is  used  by  the  network  security 
manager  lo  enter  and  display  configuration  information, 
manage  controllers,  and  review  controller  status  and  audit 
information. 

The  following  data  files  are  used  by  I  he  KI)C  software: 

LAN  Configuration  Film  This  (ilo  contains  information  about 
the  configuration  of  controllers,  KDCs,  and  other  nodes  on  the 
LAN-  All  KDC/  nodes  must  have  the  same  information  in  their 
configuration  files  lor  correct  operation. 

Controller  Status  Film  This  file  cwiinins  information  about  the 
status  of  controllers  and  their  eommuniailioii  with  this  KDC. 
A  separate  file  is  maintained  by  each  KDC. 

Audit  History  File:  This  file  contains  ali  of  the  audit  evonln 
recorded  by  this  KDC.  The  lo\ el  of  auditing  can  be  selected 
separately  for  each  controller  or  KDC. 

KDC  DKSNC  Controller 

The  software  works  together  with  the  DKSNC  controller  utl.ached 
to  the  KDC  node  to  function  as  a  KDC.  Using  thia  KDC  DKSNC 
controller  to  help  the  KDC  node  lias  several  advantages: 

•  Messages  bent  by  the  KDC  mule  are  encrypted  by  the  KI)C 
controller.  This  is  much  faster  tliun  using  software  entry  ption. 

•  Kxcept  for  the  key  that  is  displayed  when  u  controller  is 
initialized,  there  are  ho  ‘red*  keys  stored  on  the  KDC  node.  AH 
encryption  keys  are  encrypted  when  stored  on  the  KDC  node. 

When  a  key  is  used,  il  is  decrypted  by  the  KI)C  controller 
using  a  key  that  is  only  known  to  the  KDC  controller.  This 
prevents  someone  with  read-only  access  to  the  informat  ion  on 
the  KDC  node  (e  g.,  access  to  backup  tapes)  from 
compromising  the  security  of  the  network. 

•  The  KDC  coat . .illcr  generates  encryption  keys  for  the  K1)C  as 
they  are  needed  This  idso  prevents  unencrypted  keys  Iron: 
being  present  on  the  KDC  node. 

Hardware  Design 

A  DKSNC  controller  can  be  considered  to  be  a  combination  of  an 
encrypting  Kthernet  bridge  and  a  Thin  Wire  Ktheruel  concentrator. 
The  cuncentrnior  on  the  nodi*  side  of  a  DKSNC  controller  is  design, 
unlike  a  normal  concentrator,  so  that  a  frame  t  ransmitted  on  one 
node  port  is  not  automatically  transmitted  on  the  other  ports. 

This  alb  W3  the  controller  to  enforce  the  I/A  IN  access  control  policy 
between  nodes  on  different  ports. 

Controllers  are  compatible  with  the  Kthernet  and  IKKK  8U2.II 
standards  tu  allow  interoperability  with  any  products  that  conform 
to  •  ose  standards. 

C/Otit. "oilers  contains  a  Motorola  08000  CPU  chip  und  UOM 
containing  the  code  that  is  *  xc.-uted  when  a  controller  is  first  used. 
There  are  also  various  memories  u>  store  downline  loaded  rode, 
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information  about  associations  code  in  ROM,  RAM  for  codr,  RAM 
for  association  storage,  *nd  RAM  for  packet,  storage. 

Sonic,  of  tin:  memory  in  a  controller  is  preserved  over  power 
failures  of  I*’***  t  han  72  hours  through  the  use  of  capacitors.  This 
memory  is  used  to  preserve  enough  information  so  that  the 
controller  does  not  have  to  he  manually  initialized  after  a  power 
failure.  The  preserved  information  includes  the  master  key  for  the 
controller,  sequence  numbers  used  between  the  controller  and  the 
KlK's  on  the  I. AN,  and  the  cryptographic  checksum  for  the 
downline  loaded  image.  If  a  DESNC  controller  is  opened,  power  is 
removed  from  this  memory  to  reduce  the  chance  that  the 
information  will  be  used  to  compromise  the  nodes  attached  to  the 
coni  roller. 

The  front  panel  of  a  DESNC  cntiliollcr  contains  lights  that 
indicate  the  state  of  the  controller,  a  keypad  that  is  used  to 
initialize  I  he  controller,  and  a  key  switch  that  is  used  to  activate  the 
keypad  There  is  also  a  Bypass  pushbutton  thul  can  always  bo 
pressed  to  request-  that  the  controller  enter  Bypass  state. 

DESNC  coni  rollers  oxecule  complete  self- lest  code  when  they 
slnri  upeiatioii.  and  several  tests  are  run  regularly  during 
opei <u it >:j  i»f  a  controller  to  detect,  any  failures  before  tin'  security 
of  the  ikiiIc'-  connected  to  the  controller. 

Relationship  to  the 
Trusted  Network  Interpretation 

Although  the  Ethernet  Kiiliamed-SeturilY  System  was  not 
designed  specilhally  to  satisfy  cryptographic  requirements  for  the 
prc.ii  t  imn  of  dassilied  information,  the  urchileeUire  anti  security 
policy  of  the  system  permits  nil  evaluation  in  accordance  with  the 
Trusted  Network  Interpret >itiotij7|  (TNI)  in  a  variety  of  dillemil. 
ways  (Even  if  the  system  is  evaluated,  it  would  only  be  useful  in 
environments  where  it  is  appropriate  to  use  DKS  encryption  ) 

Network  Evaluation:  A  LAN  consisting  of  1) ESN v*  coni  rollers, 
a  set-  of  KlK’s.  and  several  single-user  workstations  cun  be  viewed 
as  a  single  trusted  system,  where  the  subjects  lire  the  users  of  the 
workstations  and  the  only  supported  objects  are  Ethernet  frames. 
Elicit  a  net  work  system  -atislies  many  of  I  lie*  TNI  rrcpiireinenl  s  at 
the  Bl  ( lass 

In  support  of  mandatory  security,  users  (and  then  nodes)  are 
assigned  explicit  secrecy  and  iiilognly  levels.  Ethernet  frames  do 
imt  mni am  explicit  sec* cry  and  integrity  labels  tin*  labels  are 
unpin  it  in  the  key  used  to  eucypt.  the  Inline.  Because  j.eyy  are 
selectively  assigned  on  a  node- pair  basis  tlio  fact  that  the  users  of 
two  workstations  can  communicate  means  that  they  arc  authorized 
Tor  a  common  seen-  -  and  integrity  level  The  sensitivity  level  of  a 
given  frame  can  thus  he  deb  mimed  by  examining  the  source  and 
destination  addresses  in  the  frame  in  conjunction  with  informal-inn 
stored  m  the  KDC  database.  [When  multilevel  nodes 
communicate,  it  may  not  be  possible  to  determine  the  level  of 
frames  exchanged,  depending  on  the  access  control  policy  used  by 
the  LAN.  In  these  cases,  it.  is  only  possible  to  determine  a  possible 
range  of  levels  for  each  Ethernet,  frames.] 

I  )isi  retioiiary  access  control  is  supported  in  the  sense  that 
DESNC  controllers  will  prevent  a  frame  from  being  received  by  any 
workstation  other  than  the  destination  node  requested  by  the 
transmit  ter 


Component  .Evaluation:  An  individual  DKSNC  controller  can 
be  viewed  us  a  network  component  of  type  ‘MA\  providing 
functionality  for  MAC  and  audit.  It  should  satisfy  the  minimum 
Bl  class  requirements  for  MI)  components.  If  the  component  is 
restricted  to  connecting  one  single- user  workstation  to  each  port,  it 
would  also  provide  functionality  for  DAC  ami  identification  and 
authentication,  ami  therefore  satisfy  the  minimum  Bl  class 
requirements  for  Ml  A!)  components. 

As  uu  alternative,  DKSNC  controllers  and  a  set  of  KDCs  can  be 
viewed  as  a  network  component  to  provide  the  same  functional ily. 
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ABSTRACT 

Trusted  distributed  systems  differ  from  trusted  monolithic  systems  In  that  the  medium  linking 
the  components  of  the  distributed  system  may  be  subject  to  wiretapping  threats.  This  Las 
led  to  a  misconception  that  the  primary  concern  In  covert  channel  analyses  of  distributed 
systems  should  be  the  misuse  of  protocol  fields  as  a  means  to  covertly  signal  information  to 
wiretappers  having  access  to  the  communications  medium.  Depending  upon  the  network's 
environment  this  may  not  be  a  problem  at  all.  However,  all  networks  do  have  Internal  host- 
to-host  channels  that  must  be  analyzed  In  order  to  satisfy  the  assurance  requirements  of 
distributed  systems  at  the  B2  level  and  higher.  This  paper  describes  a  layered  approach  for 
analysis  of  these  internal  channels  that  is  consistent  with  the  way  in  which  communications 
networks  are  actually  designed  and  built.  Additionally,  the  use  of  embedded,  network-based 
access  controls  is  proposed  as  a  means  to  prevent  certain  host-to-host  channels. 


1.  Introduction 

This  paper  addresses  two  distinct  ways  In  which  information 
contained  within  a  securo  distributed  system  or  network  can 
be  covertly  compromised.  The  first,  the  threat  of 
wiretapping  or  compromise  of  the  network  medium  has 
been  discussed  in  the  literature  although  it  does  not  seem 
to  fit  the  traditional  definitions  of  the  covert  channels.  It  Is 
pointed  out  that  networks,  especially  Local  Area  Networks 
(LANs)  are  not  necessarily  subject  to  this  threat,  but  if  they 
are,  the  threat  may  require  the  redefinition  of  the  term 
covert  channel  as  well  as  changes  in  the  ways  that  such 
systems  are  modeled. 

The  second  mechanism  is  the  traditional  covert  channel  in 
which  a  system  resource  not  normally  used  as  an  object  to 
contain  information  is  used  to  signal  information  between 
subjects  or  users  of  the  system.  Both  the  desire  to  evaluate 
components  for  use  in  building  network  systems  and  the 
complexity  of  such  systems  (and  even  the  components) 
makes  It  difficult  to  analyze  networks  effectively  with 
traditional  covert  channel  techniques.  Further,  the 
interconnection  of  multiple  trusted  computer  systems  raises 
the  possibility  that  a  flaw  In  one  system  can  be  exploited  by 
users  in  other  systems  leading  to  the  possibility  of  a  covert 
channel  that  spans  the  network. 

A  layered  method  of  analysis  Is  proposed  that  closely 
follows  the  ways  in  which  such  systems  are  designed  and 
constructed  In  practice.  If  such  channels  must  be 
considered,  techniques  are  available  to  reduce  their 
bandwidth.  This  section  concludes  with  the  discussion  of 
one  such  method  based  on  the  introduction  of  host  to  host 
access  controls. 


2.  Background 

The  National  Computer  Security  Center  has  developed  the 
Trusted  Network  Interpretation  (TNI)  [1],  to  be  used  in  the 
evaluation  of  trusted  network  systems  and  their 
components.  The  TNI  reflects  two  different,  and  sometimes 
conflicting,  perspectives  on  the  overall  security  problem: 

(1)  an  extrapolation  of  the  trusted  system  principles 
from  the  Trusted  Computer  System  Evaluation 
Criteria  (TCSEC)  [2]  into  a  distributed  environment, 
and 

(2)  a  communications  security  perspective  that  Is 
concerned  with  protecting  the  integrity  and  secrecy 
of  communications  within  potentially  hostile 
environments. 

The  TNI  addresses  both  areas,  with  Part  I  ratings  defining 
the  security  policy,  authentication,  assurance  and 
documentation  requirements  for  loosely-coupled  distributed 
computing  systems,  and  Part  II  ratings  addressing  the 
security  of  the  interconnecting  communications  paths. 

The  differing  emphases  of  these  perspectives  has  lead  to 
confusion  in  the  area  of  covert  channel  analysis.  The  TNI 
continues  the  requirement  to  address  covert  channels  within 
the  Individual  computing  systems  and  observes  that  there 
are  additional  instances  of  covert  channels  associated  with 
communications  between  components:  i.e.,  the  exploitation 
of  network  protocol  Information. 

The  evaluation  of  trusted  systems  must  provide  for  the 
analysis  of  both  overt  and  covert  channels.  Within  trusted 
computer  systems,  overt  channels  result  from  the  use  ot  the 
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system's  protected  data  objects  to  transfer  Information 
directly  from  one  subject  to  another.  Analysis  of  the  system 
must  lead  to  the  conclusion  that  all  overt  channels  conform 
to  the  system's  security  policy. 

On  the  other  hand,  covert  channels  use  entitles  not 
normally  viewed  as  data  objects  to  transfer  Information  from 
one  subject  to  another  In  violation  of  the  system's  security 
policy.  Storage  channels  result  from  an  exploitation  of  a 
shared  storage  resource,  while  timing  channels  result  from 
the  modulation  of  the  system's  response  time. 

The  TCSEC  and  TNI  provide  the  following  definitions  cf 
such  channels: 

Covert  Channel 

A  communications  channel  that  allows  a  process  to 
transfer  information  that  violates  the  system’s  security 
policy.  A  covert  channel  typically  communicates  by 
exploiting  a  mechanism  not  Intended  to  be  used  for 
communication. 

Covert  Storage  Channel 

A  covert  channel  that  Involves  the  direct  or  Indirect 
writing  of  a  storage  location  by  one  process  and  the 
direct  or  indirect  reading  of  the  storage  location  by 
another  process.  Covert  storage  channels  typically 
involve  a  finite  resource  ( o.g„  sectors  on  a  disk,  device 
status  flags,  etc.)  that  is  shared  by  two  subjects  at 
different  security  levels. 

Covert  Timing  Channel 

A  covert  channel  In  which  one  process  signals 
information  to  another  by  modulating  Its  own  use  of 
system  resources  (e.g.,  CPU  time)  in  such  a  way  that 
this  manipulation  affects  the  real  response  time 
observed  by  the  second  process. 

Historically,  most  methods  for  dealing  with  covert  channels 
within  computer  systems  have  been  ad  hoc.  |3j  describes 
the  approach  used  for  performing  a  covert  channel  analysis 
during  the  Honeywell  Multlcs  evaluation.  Mechanical  covert 
channel  analysis  tools  have  been  developed  for  systems 
characterized  by  formal  top  level  specifications.  These 
tools,  typified  by  the  SRI  MLS  Flow  Tool  [4],  are  based  on 
the  assignment  of  security  levels  to  each  TCB  resource 
attribute  and  the  geneiatlon  of  formulas  which,  If  proven  to 
be  true,  ensure  that  all  information  transfers  within  the 
specification  conform  to  the  system’s  security  policy.  The 
Shared  Resource  Matrix  (SRM)  methodology  proposed  by 
[5]  is  an  intermediate  approach  (between  the  ad  hoc 
methods  and  information  flow  tools)  that  can  be  used  at  a 
variety  of  different  levels  of  abstraction. 

The  development  of  covert  channel  analysis  methods,  such 
as  those  mentioned  above,  results  from  the  TCSEC 
requirement  to  perform  covert  channel  analyses  beginning 
at  the  B2  assurance  level.  Since  there  are  only  two  local 
area  network  components  known  to  be  under  evaluation  by 
the  NCSC  at  the  time  this  paper  was  written,  there  is  not  a 
significant  amount  of  literature  available  on  the  subject  of 
covert  channels  In  LANs. 


3.  The  Wiretap  Threat 

The  TNI  seems  to  assume  that  the  primary  covert  channel 
threat  to  networks  results  from  attacks  on  the  network 
communications  medium  by  wiretappers  who  are  not 
“subjects"  of  the  network.  Both  of  the  references  cited  by 
the  TNI  In  this  area,  mention  the  existence  of  covert 
channels  from  an  untrusted  subject  to  an  external 
wiretapper.  [6]  addresses  the  inability  of  end-to-end 
encryption  hardware  to  protect  against  malicious  use  of 
address,  length,  and  timing  Information  by  untrusted  host 
software.  [7]  defines  the  same  three  mechanisms  within  a 
LAN  environment  and  describes  the  results  of  an 
experiment  to  measure  the  bandwidth  of  the  addressing 
channel. 

As  described  in  the  following  sections,  we  believe  this 
emphasis  on  covert  channels  Involving  wiretappers  is 
somewhat  misleading.  Within  LAN  environments,  at  least, 
wiretap  threats  can  be  addressed  In  the  same  way  that  they 
are  addressed  in  any  other  trusted  facility:  by  physical, 
procedural,  and  administrative  security  mechanisms. 

The  mechanisms  Identified  by  [6]  and  [7]  involve  the 
modulation  of  protocol  fields  or  other  externally  visible 
aspects  of  the  communications  packet.  Girling  Identifies  the 
following  three  methods  of  exploiting  conventional  LAN 
interface  devices  to  covertly  signal  Information  to  a 
wiretapper: 

LAN  Address  A  covert  storage  channel  is  possible 
when  a  high-level  hos  process  can 
address  packets  to  multiple 
destinations  and  a  wiretapper  can 
observe  the  sequence  of  packets. 

Packet  Length  A  covert  storage  channel  Is  possible 
when  a  high-level  host  process  can 
determine  the  length  of  outgoing 
packets  and  the  wiretapper  can 
observe  the  lengths  of  these 
packets. 

Inter-Packet  Delay  A  covert  timing  channel  is  possible 
when  a  high-level  host  can 
modulate  the  delay  between 
outgoing  packets  and  a  wiretapper 
can  observe  and  measure  these 
delays. 


3.1.  Bandwidths 

Both  [6]  and  [7]  point  out  that  the  bandwidths  of  such 
channels  may  often  be  in  excess  of  100  bits  per  second.  It 
appears  that  these  estimates  understate  the  potential 
bandwidths  that  could  be  achieved  using  current  LAN 
devices. 

(1)  The  IEEE  802.3  specification  defines  a  six-byte 
destination  address  field  and  packet  lengths  from 
64  to  1518  octets.  Assuming  all  addresses  can  be 
generated  without  detection,  the  width  of  the 
address  channel  bandwidth  Is  potentially  48 
bits/packet. 
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(2)  The  increased  performance  of  readily  available 
LAN  hardware  means  that  Information  can  be 
compromised  at  a  proportionally  higher  rate. 
Ethernet  boards  are  available  with  typical 
throughputs  of  500  Kbps,  and  should  be  able  to 
generate  packets  continuously  at  a  rate  of  50 
packets  per  second. 

From  such  assumptions,  the  bandwidth  of  the  address 
channel  In  an  Ethernot-like  LAN  could  be  on  the  order  of 
2400  bits/second,  As  higher  throughputs  become 
commonplace,  the  potential  bandwidth  of  these  channels 
will  further  increase. 

That  such  signaling  mechanisms  exist  is  not  In  dispute, 
Whether  they  need  to  be  considered  in  every  network 
system  is  open  to  question.  If  the  system  or  component 
being  examined  is  subject  to  a  wiretap  threat,  there  may  be 
implications  that  require  modification  of  the  system  security 
policy  and  the  definition  of  a  covert  channel. 


3.2,  Is  the  Threat  Universal? 

Are  some  networks  exempt  from  a  wiretap  threat?  We 
believe  that  this  is  certainly  true  for  some  LANs,  but  It  may 
not  be  the  case  for  geographically  distributed  network 
systems.  LANs  operating  within  a  physically  controlled 
environment  or  routed  through  protected  wireways  should 
be  relatively  immune  to  wiretap  attacks. 

In  order  to  clarity  this  issue,  consider  a  series  of  tour 
different  systems’,  as  follows: 

(1)  A  trusted  monolithic  computing  system,  as  addressed 
by  the  TCSEC. 

(2)  A  trusted  tightly-coupled  multi-processor,  multi- 

programmed  computing  system,  as  described  in 
Appendix  B.4.3  of  the  TNI. 

(3)  A  trusted,  loosely-coupled  distributed  computing 

system,  with  individual  host  computers  operating  at 
potentially  different  security  levels.  The  host  computers 
are  interconnected  by  a  conventional  IEEE  802.3  LAN, 
and  the  computers  and  medium  are  maintained  within 
the  same  protected  facility. 

(4)  A  trusted,  loosely-coupled  distributed  computing 

system,  with  Individual  host  computers  operating  at 
potentially  different  levels,  but  with  each  host  computer 
separately  protected. 

For  each  architecture,  consider  the  implications  of  allowing 
an  anonymous  wiretapper,  with  arbitrary  equipment,  access 
to  the  backplane  of  each  of  the  four  systems.  Does  this 
access  constitute  a  potential  for  a  compromise  of 
information,  a  violation  of  the  system’s  security  policy? 
Using  the  broad  definition  of  "policy”,  the  answer  would 
certainly  have  to  be  "yes".  Clearly,  each  example  provides 
the  potential  for  unauthorized  disclosure  and  modification  of 
data. 


'  The  TCSEC/TN1  terminology  Is  used  here,  so  that  the  term 
"system"  refers  to  a  collection  ot  computer  and  communications 
hardware,  software,  and  firmware  that  performs  all  o!  the  functions 
defined  In  Part  I  ot  the  TNI.  Specifically,  a  system  is  capable  ot 
Identifying  and  mediating  access  at  Ihe  human  user  level. 


The  significant  point  Is  that  in  the  first  two  cases  the  vendor 
and  the  NCSC  assume  that  the  system  will  be  operated 
according  to  the  assumptions  In  the  vendor's  Trusted 
Facility  Manual.  If  the  monolithic  computer  system  can  be 
considered  a  degenerate  case  of  the  general  computer 
system,  the  corresponding  Intrusion  would  be  tantamount  to 
the  removal  of  the  cover  from  the  computer  system,  and 
allowing  the  wiretapper  access  to  bus  signals  and  other 
backplane  activity. 

If  the  operators  of  any  trusted  facility  allow  unlimited  access 
to  the  internals  of  their  system,  then  there  is  significant  risk 
of  data  compromise  at  a  very  high  bandwidth.  Conversely,  if 
It  can  be  assumed  that  the  facility  and  its  equipment  are 
properly  protected,  then  the  covert  channel  analysis  can  be 
limited  to  potential  channels  between  authorized  subjects 
operating  under  control  of  the  TCB/NTCB. 


3.3.  Security  Compliant  Communications 
The  TNI  references  appear  to  make  the  assumption  that 
networks  are  necessarily  subject  to  wiretap  threats,  and 
ignore  the  traditional  physical,  procedural  and  administrative 
solutions  to  physical  tampering  used  In  trusted  computer 
facilities,  but  Appendix  B  of  the  TNI  describes  three 
different  methods  for  ensuring  security-compliant 
communications. 

(1)  Documenting  constraints  In  the  Trusted  Facility 
Manual,  thereby  deterring  an  assessment  of 
compliance  to  accreditation. 

(2)  Providing  suitable  end-to-end  communications 
security  techniques. 

(3)  Administrative  restriction  of  use  of  the  channel. 

If  the  assumption  is  made  in  the  Tmsted  Facility  Manual 
that  the  network  Is  operated  in  a  protected  environment, 
there  should  be  no  need  to  consider  covert  channels  to 
wiretappers.  This  explicit  assumption  is  made  implicitly  in 
the  evaluation  of  trusted  computer  syr  terns.  For  local  area 
networks,  in  particular,  It  appears  to  be  a  reasonable 
assumption  to  make,  considering  cost  and  benefit  tradeoffs. 


3.4.  Policy  Implications 

This  still  leaves  open  the  question  of  whether  or  not 
information  flows  from  a  subject  (user)  of  a  system  to  a 
wiretapper  constitute  covert  channels  in  the  usual  sense  of 
the  term.  The  answer  depends  upon  the  definition  of 
security  policy,  since  a  covert  channel  Is  defined  as  "a 
communications  channel  that  allows  a  process  to  transfer 
Information  in  a  manner  that  violates  the  system's  security 
policy”.  The  TCSEC  further  defines  security  policy  as  "... 
the  set  of  laws,  rules  and  practices  that  regulate  how  an 
organization  manages,  protects,  and  distributes  sensitive 
information".  This  appears  to  categorize  theft  of  computer 
tape  containing  classified  information  as  being  a  covert 
channel;  however,  that  Is  clearly  not  what  is  intended  for 
the  covert  channel  analyses  performed  by  system  vendors. 
Covert  channel  analyses  focus  on  the  use  of  entities  not 
normally  viewed  as  data  objects  to  transfer  information  from 
one  subject  to  another  [subject]  [5],  Subjects,  In  turn,  are 
entitles  that  operate  within  the  control  of  the  TCB  (or  NTCB) 
cn  behalf  of  human  users.  This  appears  to  have  at  least 
one  of  the  following  Implications: 
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(1)  The  wiretapping  threat  is  unrelated  to  the  subject  o f 
covert  channel  analysis  (and  requires  a  physical, 
communications,  or  administrative  security 
solution);  or 

(2)  Wiretappers  can  be  “subjects",  and  consequently 
must  be  addressed  by  the  security  policy  model  for 
the  network  system;  or 

(3)  The  manner  in  which  covert  channel  analyses  have 
been  done  for  monolithic  computer  systems  must 
be  changed  to  include  threats  to  the  physical 
security  of  the  system. 

We  dismiss  the  third  altemativo  as  unduly  overloading  the 
notion  of  covert  channels.  For  a  system  to  be  secure,  a 
wide  variety  of  potential  threats  must  be  countered.  When 
the  evaluation  and  accreditations  are  properly  carried  out, 
this  will  be  done  in  such  a  way  as  to  cover  operational  and 
environmental  threats  as  well  as  architectural  ones.  There 
is  no  need  to  include  all  such  threats  under  the  umbrella  of 
“coved  channel  analysis".  The  choice  between  the  first  two 
alternatives  is  less  clear  cut. 

At  the  B2  level  of  evaluation,  both  the  system’s  security 
policy  model  and  the  covert  channel  analysis  are  rather 
informal.  The  search  for  covert  channels  Is  usually  based 
on  the  system's  Descriptive  Top  Level  Specification  (DTLS) 
which  may  be  somewhat  Imprecise.  At  the  A1  level,  covert 
channel  analysis  is  conducted  with  respect  to  the  system's 
Formal  Security  Policy  Model  (FSPM)  and  Formal  Top 
Level  Specification  (FTLS)  using  “formal  methods",  usually 
with  the  aid  of  mechanical  tools.  In  either  case,  both  the 
security  policy  and  the  system  specification  must  define  the 
domain  of  the  analysis.  If  the  covert  channel  analysis  Is  to 
include  wiretap  threats  tnen  the  policy  and  specification 
must  include  wiretappers.  We  know  of  no  cases  to  date  in 
which  this  issue  has  been  explicitly  addressed  in  network 
security  policy  models  or  specifications. 

These  observations  lead  to  a  conclusion  that  while 
information  compromise  via  wiretap  channels  can  be 
performed  using  techniques  similar  to  those  used  for  covert 
channels,  the  mechanisms  are  not  covert  channels  under 
the  definition  quoted  above  with  the  usual  policy  definitions 
and  specification  paradigms.  In  this  case,  the  fault  lies  with 
the  policies  and  specifications.  If  a  system  or  component 
will  be  subject  to  a  wiretap  attack  and  it  is  desired  to 
evaluate  the  threat  as  a  part  of  a  covert  channel  analysis, 
the  policy  for  the  system  must  clearly  consider  the 
existence  of  wiretappers  and  define  the  extent  (if  any)  to 
which  they  are  permitted  access  to  Information  contained  in 
the  system.  A  system  specification  subject  to  covert 
channel  analysis  must  also  explicitly  consider  wiretappers 
as  potential  subjects  and  describe  their  accesses  In  relation 
to  other  system  entities.  These  additions  will  clearly  Impact 
the  usual  security  analysis  of  the  system  as  well  as  Its 
covert  channel  analysis. 


4.  Covert  Channels  Between  Network  Subjects 

This  section  describes  a  method  for  Identifying  and 
resolving  the  remaining  Internal  covert  channels  within  a 
network  system.  Within  a  distributed  system,  Internal 
channels  tend  to  be  between  processes  existing  on  different 
hosts,  where  such  channels  would  occur  on  a  single  host  in 
a  monolithic  computer  system.  The  level  of  complexity 
resulting  from  Interconnecting  arbitrary  hosts  running 
arbitrary  applications  programs  may  appear  unmanageable 
at  first,  because  of  the  potential  for  large  numbers  of 
interactions  between  heterogeneous  host  computers, 
operating  systems  and  processes  that  must  be  considered. 


4.1 .  Layering  and  Abstraction 

Fortunately,  most  communications  systems  (even  untrusted 
ones)  are  designed  and  built  In  a  highly-structured  manner 
that  can  be  used  to  reduce  the  complexity  of  covert  channel 
analyses.  The  ISO  Reference  Model  of  Open  Systems 
Interconnection  (OSI)  provides  a  framework  for  defining 
communications  protocols.  The  actual  layers  of  protocoi 
that  are  Implemented  differ  from  network  to  network, 
however,  the  purpose  of  each  layer  is  to  offer  certain  well- 
defined  services  to  the  higher  layers,  shielding  those  layers 
from  implementation  details.  Figure  1  depicts  the  network 
architecture  used  in  this  paper,  based  upon  the  OSI 
reference  model. 
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Figure  1.  Network  Reference  Model. 


Without  going  too  far  afield,  it  Is  helpful  to  review  the  basic 
principles  that  are  used  in  the  design  of  communications 
networks,  for  these  same  principles  can,  and  should,  be 
applied  to  the  development  of  trusted  network  systems.  As 
described  in  [8],  the  identification  of  protocol  layers  is  based 
primarily  on  the  need  to  deal  with  a  different  level  of 
abstraction,  with  each  layer  performing  a  well  defined 
function.  Strict  layering  Is  usually  observed,  in  order  to 
encapsulate  the  services  that  are  performed  and  to  provide 
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some  degree  of  protocol  Independence.  Without  such 
abstractions  and  layering,  it  Is  unlikely  that  a  network  as 
complicated  as  the  DoD  Internet  could  ever  be  made  to  run. 

In  the  following  discussion,  layers  protocols  exist  between 
pear-level  entities,  while  service  Interfaces  exist  between 
layer  n  and  (n+1)  entitles. 


4.2.  Trusted  Protocol  Design  and  implementation 

Unfortunately,  the  emphasis  on  protocol  layering  and 
abstractions  in  the  communications  world  Is  not  readily 
apparent  In  the  TNI2.  However,  such  a  layered  protocol 
view  of  the  world  is  not  Inconsistent  with  the  TNI,  and 
Indeed  provides  ari  excellent  model  for  analysis  of  trusted 
network  systems. 

Consider  a  trusted  implementation  of  a  layered  network 
component.  From  a  communications  perspective,  this 
component  would  Implement  protocol  layers  1  through  n, 
which  would  provide  layer-n  services  to  layers  (n+1)  and 
above.  From  a  trusted  system  perspective,  this  component 
would  have  its  own  security  policy  (and  model),  which 
would  define  access  of  layer-(n+1)  subjects  to  objects 
existing  at  the  service  Interface  between  layers  n  and  (n+1). 
For  example,  a  trusted  network  layer  (and  below) 
implementation  would  mediate  access  of  transport  layer 
subjects  to  network  packet  objects.  Processes  and  flies  do 
not  exist  at  the  network  layer  of  abstraction;  only  transport- 
layer  protocol  entities  and  packets  (or  datagrams)^. 

It  must  be  realized  that  many  networking  implementations 
do  not  necessarily  use  a  separate  process  for  each 
individual  layer  of  the  protocol  hierarchy,  For  example, 
UNIX  systems  commonly  Implement  TCP/IP  within  a  single 
process  rather  than  as  separate  processes.  When  a  single 
process  is  used  to  implement  more  than  one  protocol  layer, 
the  combined  layers  must  be  treated  as  a  single  layer  for 
the  purposes  of  covert  channel  analysis. 


4.3.  Covert  Channels  Within  Protocols 
This  same  model  can  be  used  for  performing  covert 
channel  analyses  of  trusted  network  systems,  Each 
successive  layer  ot  the  protocol  stack  could  be  analyzed 
with  respect  to  the  covert  channels  that  exisl  within  that 
layer  and  lower  layers.  For  example,  an  layer*n  analysis 
would  concentrate  on  the  existence  of  covert  channels 
through  the  layer-n  implementation  that  can  be  utilized  by 
the  various  layer-(n+1)  entitles  (subjects)  through  the 
service  interface. 

The  covert  channel  analysis  for  a  trusted  layer-n  component 
would  be  concerned  only  with  the  Identification  and  analysis 
of  unauthorized  Information  channels  between  pairs  of 
layer-(n+i)  subjects,  It  would  not  provide  for  the 
identification  of  covert  channels  within  higher  layers,  and  it 
can  not  be  responsible  for  auditing  or  resolving  any 
channels  that  might  exist  within  higher  layers,  It  is  a  basic 
rule  of  layered  protocol  design  that  a  lower-level  protocol 
should  not  read  or  modify  the  contents  of  higher-level 
protocols.  Similarly,  higher-level  protocols  should  not 

2  For  example,  Appendix  A  (Network  Components)  does  not 
include  an  example  of  a  layered,  distributed  component,  but  rather 
shows  monolithic  "boxei"  Interconnected  with  wires. 

2  Consequently,  H  Is  not  possible  tor  a  trusted  network-layer 
implementation  to  qualify  at  a  TNI  "system",  since  It  does  not  deal  with 
the  identiticalion  and  mediation  of  human-user  entities. 


access  or  modify  resources  used  by  lower-level  protocols, 
except  through  the  vocabulary  of  operations  provided  by  the 
protocol  Interface. 


4.3.1.  Layering  Within  LAN  Systems 
Most  distributed  systems  In  use  today  rely  on  a  combination 
of  physical  and  logical  separation  at  the  Interfaces  between 
certain  layers  In  the  protocol  hierarchy.  A  typical  LAN 
architecture  (Figure  2)  consists  of  multiple  hosts,  each 
having  a  dedicated  LAN  co-processor  board  that  performs 
packet  transmission,  reception,  limited  error  control,  etc. 
These  boards  generally  implement  the  physical  and  link 
layers,  and  sometimes  the  network  and  transport  layers  as 
well.  The  traditional  rationale  for  this  separation  has  been 
performance  rather  than  security. 


Host  A  Host  B 


Figure  2.  Typical  LAN  Architecture. 

Such  physical  separation  provides  assurance  that  host 
processes  do  not  have  direct  access  to  the  physical 
transmission  medium  or  any  data  associated  with  the 
protocol  layers  Implemented  on  the  co-processor,  unless 
the  co-prooessor  interface  explicitly  provides  such  access. 
User-level  processes  do  not  have  any  other  means  of 
accessing  the  Internal  registers  of  the  co-processor  board, 
observing  the  contents  or  addresses  of  individual  packets, 
etc.  The  net  effect  of  this  separation  Is  to  limit  the  available 
mechanisms  for  covert  communications  among  legitimate 
hosts  on  the  network. 

Given  an  appropriate  software  architecture  in  which 
processes  are  permitted  to  communicate  only  through 
carefully  controlled  mechanisms  managed  by  the  TCB,  the 
same  degree  of  assurance  should  be  possible  using  logical 
separation.  In  either  case,  careful  definition  of  the  service 
interface  between  layers  Is  required  and  the  Implementation 
must  ensure  that  It  Is  not  possible  to  bypass  this  Interface. 
Note  that  the  mechanisms  used  to  Implement  a  layered 
protocol  securely  will  have  much  In  common  with  those 
used  to  Implement  TCBs, 
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4.3.2.  Analysis  Techniques 

If  the  Shared  Resource  Matrix  (SRM)  methodology  [5]  is 
used,  we  believe  the  SRM  operations  can  be  identified  by 
closely  inspecting  the  service  interlace  between  the  trusted 
layer-n  component  and  the  external  layer-(n+1)  subjects.  A 
variety  of  resources  must  be  considered,  both  those  visible 
at  the  service  interface  and  those  embedded  within  the 
layer-n  component.  However,  It  Is  not  necessary  to 
address  any  internal  resource  whose  attributes  are  invisible 
to  the  higher-level  protocols,  For  example,  It  would  not  be 
necessary  to  address  the  number  of  retransmissions 
required  to  reliably  send  a  packet  to  a  remote  peer  entity,  if 
the  number  of  retries  Is  hidden  within  the  abstraction  of  the 
lower  protocol  layers.  The  possibility  of  composing 
matrices  at  the  Individual  levels  to  provide  system  level 
analysis  is  an  interesting  subject  for  further  research. 


4.4.  Host-to-Host  Channels 

The  preceding  discussion  has  presented  a  general 
approach  to  addressing  Internal  cover!  channels  within 
individual  layers  of  a  trusted  network  system.  However, 
protocol  layers  may  be  addressed  as  a  group  having  a 
common  hardware  platform  or  run-time  services,  for 
example,  the  lower  level  protocols  that  normally  reside  on 
an  Ethernet  LAN  interface  board  or  the  higher-level  end-to- 
end  protocols  (e.g.,  FTP,  Telnet)  that  normally  reside  with 
the  software  of  Individual  hosts.  Thus,  within  local  area 
network  systems  having  dedicated  LAN  hardware,  It  makes 
sense  to  consider  separately  the  covert  channels4  that  may 
exist  within  the  underlying  network  layers  from  those  within 
the  individual  hosts.  If  this  approach  is  taken,  one  can  then 
categorize  intar-process  covert  channels  as  either  intra-host 
or  inter-host: 

Intra-Host  Covert  channels  that  exist  between  subjects 
on  the  same  host  computer  can  be  identified 
and  resolved  within  that  host,  Independent  of 
any  host-to-host  connections.  The 
Identification  of  such  covert  channels  Is 
extensively  treated  in  the  literature.  If  a 
mechanism  is  identified  as  providing  a 
potential  covert  channel,  then  that  mechanism 
should  not  be  used  either  within  the  host  or  In 
conjunction  with  network  transfers. 

Inter-Host  Covert  channels  between  subjects  on  different 
hosts  can  be  addressed  in  two  steps,  with 
host-to-host  channels  addressed  at  the  lower 
layer,  and  process-to-process  channels 
addressed  (as  above)  within  each  host. 

It  Is  possible  that  a  security  llaw  that  has  been  deemed 
acceptable  within  a  single  host  may  not  be  acceptable 
when  the  host  Is  connected  to  a  network.  This  Is  because 
the  overt  communications  channels  between  hosts  can  be 
used  to  extend  the  number  of  processes  that  can  take 
advantage  of  such  a  flaw.  Consider  Figure  3,  which  shows 
a  covert  channel  between  Processes  PI  and  P2  in  Host  A. 
If  Host  A  Is  then  interconnected  with  Host  B,  and  peer-level 
communications  protocols  are  established  between  the 

4  This  Is  the  case  K  the  underlying  network  Is  being  developed  as  a 
trusted  componeni,  and  Is  also  probably  true  even  it  untrusted  LAN 
components  arc  being  used  with  trusted  host  software. 


hosts,  It  Is  possible  that  information  could  be  covertly 
signaled  from  Pi  to  P3,  using  the  allowable 
communications  path  from  P2  to  P3.  Extended  channels 
such  as  this  (Involving  multiple  transfers)  are  equivalent  to 
those  described  by  [5]  Involving  multiple  attributes,  and  It  Is 
believed  that  they  could  be  Identified  by  the  same  method, 
i.e.,  a  transitive  closure  of  the  overall  network  matrix.  In  the 
analysis  of  covert  channels  It  is  not  sufficient  to  determine 
the  security  flaw  that  allows  information  to  work,  one  must 
also  be  concerned  with  the  nature  of  Information  that  may 
be  leaked  through  this  flaw  and  the  places  in  the  overall 
system  where  the  Information  might  be  extracted. 


Figure  3.  Example  of  an  Extended  Covert  Channel. 

iven  with  these  additional  possibilities  for  extended  covert 
channels,  the  layereo  approach  described  above  has  the 
advantage  of  being  conceptually  easier  to  follow  than 
attempting  to  address  all  the  channels  within  a  distributed 
network  system  at  the  same  level  of  abstraction.  By 
dividing  the  potential  covert  channels,  a  separation  of 
concerns  may  be  made,  and  the  two  distinct  cases  may  be 
solved  individually.  As  a  result  of  this  separation,  it  is 
possible  to  use  network-based  controls  within  trusted 
lower-level  protocols  to  significantly  reduce  the  ability  of 
higher-level  protocol  subjects  to  Interact  In  a  way  that 
violates  the  system’s  security  policies, 


5.  Network-Based  Controls 

The  fundamental  problem  to  be  solved  In  the  covert 
channel  analysis  of  a  network  system  Is  to  prevent  arbitrary 
host  processes  from  interacting  In  ways  that  may  violate 
security  policy.  As  described  above,  this  process  Is 
potentially  complex  because  of  the  need  to  address 
channels  between  arbitrary  processes  running  In  arbitrary 
host  computers. 
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One  way  of  solving  a  significant  part  of  this  covert  channel 
problem  is  to  embed  network-level  access  controls  within 
each  LAN  interface  board,  so  that  only  certain  host-to*host 
interactions  are  allowed.  If  a  particular  pair  of  hosts  is  not 
allowed  to  communicate  (at  the  packet  level),  then  it  follows 
that  covert  channels  cannot  exist  between  processes  in 
those  hosts. 

This  mechanism  will  suffice  by  itself  in  single-user 
workstation  environments  where  all  processes  within  each 
communicating  workstation  are  cumulatively  allowed  (or 
disallowed)  to  communicate  with  all  processes  in  another 
workstation.  However,  if  some  (but  not  all)  of  the 
processes  within  a  host  are  allowed  to  communicate  with 
some  of  the  processes  within  another  host,  the  covert 
channel  analysis  must  then  include  an  analysis  of  the 
mechanisms  available  within  each  host  system,  If  there 
exists  a  mechanism  within  one  of  the  hosts  that  can  be 
used  as  a  covert  channel  within  that  host,  then  the  same 
mechanism  can  also  be  used  in  conjunction  with  an  overt 
channel  provided  by  the  network  to  covertly  signal 
information  to  a  process  in  a  remote  host.  This  Is  not  a 
flaw  In  the  proposed  method  of  network-based  controls,  but 
rather  an  unrealistic  expectation  for  the  network  layer  of 
abstraction. 

The  use  of  embedded  access  controls  within  the  network 
can  also  be  used  to  reduce  the  potential  address  channel 
bandwidth  in  unprotected  LAN  environments  ( l.e .,  to 
wiretappers).  As  described  in  Section  3,  the  LAN  address 
channel  mechanism  Is  possible  when  a  high-level  host 
process  can  address  packets  to  multiple  destinations  and  a 
wiretapper  can  observe  the  sequence  of  packets  emanating 
from  this  host.  Reducing  the  number  of  authorized 
destination  addresses  available  to  a  particular  host  (and  Its 
processes)  reduces  the  width  of  the  channel  from  the  width 
of  the  LAN  address  field  to  the  number  of  bits  that  can  be 
signaled  using  authorized  destination  addresses.  For 
example,  If  there  are  16  authorized  destinations,  then  only 
four  bits  can  be  signaled  per  packet,  as  opposed  to  the  48 
bits  otherwise  available  In  the  LAN  address  field.  As 
pointed  out  in  PI.  In  the  absence  of  ways  to  force 
misdelivery  of  packets  on  tha  LAN,  there  appear  to  be  no 
host-to-host  covert  storage  channels  within  the  network 
component  Itself. 


6.  Conclusions 

This  paper  has  provided  an  architectural  basis  for  the 
definition  of  covert  channels  within  local  area  network 
environments.  Covert  channel  analyses  for  trusted  LAN 
systems  must  provide  for  Identifying  channels  between 
Individual  host  applications  running  on  top  of  the  distributed 
NTCB.  The  composition  of  a  network  system  covert  channel 
analysis  from  the  analyses  of  Individual  network  and  host 
components  Is  expected  to  be  the  primary  area  of 
investigation  for  local  area  networks  that  operate  In 
physically  protected  environments. 

In  addition,  If  the  network  must  operate  in  unprotected 
environments,  the  developers  should  provide  mechanisms 
to  protect  against  covert  channels  between  Internal 
applications  and  potential  external  wiretappers.  However,  In 
no  event  should  these  external  channels  be  the  only  area  of 
Investigation  during  a  secure  LAN  covert  channel  analysis, 


The  architecture  of  LAN-based  systems  lends  itself  to 
Implementing  access  controls  within  the  network  hardware 
Itself  In  order  to  prevent  unauthorized  host-to-host  packet 
flows.  This  reduces  the  scope  of  potential  covert  channel 
interactions  that  must  be  considered  in  a  network  system 
analysis,  Once  this  capability  Is  provided,  It  has  the 
additional  benefit  of  eliminating  most  or  all  protocol-based 
covert  storage  channels  by  preventing  Individual  host 
application  processes  from  having  direct  access  to  the 
packets  on  the  LAN  medium. 
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Abstract 

The  iKGM-1001,  Tepache,  Advanced  Key  Generation 
Module,  is  a  member  of  the  National  Security 
Agency's  family  of  standard  embedded  COMSEC 
products.  The  attached  application  example  ties 
the  iKGM-100  modulo  with  Intel's  INA  960  and 
Microsoft's  networks  (MS-NET)2  software  to 
support  a  COMSEC  local  area  network  (LAN).  One 
of  the  key  advantages  of  using  the  IKGM-100  Is 
its  high-performance,  open  architecture.  In 
COMSEC  LANs,  datagram  and  virtual  circuit 
communications  are  key  to  a  networks  successful 
implementation.  The  iKGM-100,  as  compared  to 
other  competitive  products,  can  handle  the  high 
demand  of  LAN  communications  as  well  as  support 
datagram  and  virtual-circuit  service 

Background 

As  a  result  of  a  “National  Security  Directive" 

NSDD  145  signed  by  President  Reagan  in  1984,  the 
National  Security  Agency  was  given  the  charter  of 
securing  the  Nation's  tele  and  data 
communications  network.  As  a  result  of  this  new 
charter  the  NSA  created  the  "Commercial 
Communications  Security  Endorsement  Program” 

(CCEP).  The  mission  at  the  CCEP  Is  to  provide 
Communications  Security  (COMSEC)  equipment  to  the 
market  as  quickly  as  possible.  Traditionally, 
the  designs  and  development  of  COMSEC  equipment 
was  done  In  total  by  the  NSA,  through  contract 
awards.  The  traditional  approach  required  a  7  - 
10  year  evaluation  effort  before  the  product 
reached  the  market.  The  goal  of  the  CCEP  Is  to 
reduce  that  time  to  less  than  2  years.  The  IKGM- 
100  is  qne  of  the  first  NSA  endorsed  CCEP 
devices. 

The  purpose  of  this  article  is  to  describe  how  a 
personal  computer  (PC)  workstation  can  be 
integrated  into  a  secured  communications  network 
using  the  iKGM-100  module.  The  IKGM-100 
integrated  component  must  provide  six  basic 
functions  for  data  communications.  These 
functions  are;  1)  a  security  fault  architecture 
with  complete  complements  of  cryptographic 
alarms,  2)  an  optimal  architecture  to  support 
packet  switch  and  local  area  networks 
applications,  3)  a  controlled  cryptographic 
bypass,  4)  a  robust  instruction  set  to  support 
key  distribution  and  management  functions,  5)  a 
key  cache  for  simultaneous  open  cryptographic 
associations  and  6)  a  low  development  integration 
and  product  cost.  The  key  to  obtaining  NSA 
endorsement  Is  minimizing  the  additional  security 
firmware/software  to  interface  the  COMSEC 
component.  The  IKGM-100,  an  NSA  endorsed  device, 
Is  fully  compliant  with  this  criteria. 

The  direction  of  the  secured  networks  Is  to 
support  commercially  available  protocols.  Even 
though  the  mature  protocols  lor  LAN's  are  based 
on  TCP/IP,  there  Is  a  need  to  provide  secured  LAN 
communications  implemented  on  International 
Standards  Organization  (ISO)  protocols.  The 
tocus  of  this  example  Is  to  review  Intel's  IKGM- 
100  as  it  applies  to  a  Type  I  secured  data 
network  architecture. 


This  application  example  Integrates  the  iKGM-100 
into  the  INA  960  (Intel's  Networking 
Architecture)  software  structure  to  provide  a 
secure  architecture  as  It  relates  to  an  personal 
computer  networking  environment.  The  objective 
of  this  application  Is  to  use  an  ISO  based  LAN 
with  Microsoft's  Networking  Software  (MS-NET). 

Overview 

The  IKGM-100,  Advanced  Key  Generation  Modulo,  is 
a  member  of  the  National  Security  Agenoy’s  family 
o;  standard  embedded  COMSEC  products.  The 
attached  application  example  ties  the  IKGM-100 
module  with  Intel's  INA  960  and  Microsoft's  MS- 
NET  software  to  support  a  COMSEC  LAN  environment. 
One  of  the  key  advantages  of  using  tho  IKGM-100 
is  Its  high-performance  open  architecture.  In 
COMSEC  LAN  environments,  datagram  and  virtual 
circuit  communications  are  a  key  to  a  LAN's 
successful  Implementation.  The  IKGM-100,  as 
compared  to  other  competitive  products,  can 
handle  the  high  demand  of  LAN  communications  as 
well  as  support  datagram  and  virtual-circuit 
service 

Intel's  communications  software  supports  the  Open 
System  Interconnection  Model  (OSI)  at  all  layers. 

The  MS-NET  software  Is  an  accepted  standard  of 
data  communications  for  Xenix2,  Unix  System  V, 
MS-DOS  and  IRMX  (Intel's  Real  Time  Multitasking 
Executive  software).  The  MS-NET  protocols  provide 
transparent  access  to  files  anywhere  In  the 
network.  The  MS-NET  software  is  similar  to  the 
MAP  3,0  upper  layer  protocols  and  represents 
layers  5-7  of  the  Open  System  Interconnection 
(OSI)  model. 

Intel’s  ISO  certified  (International  Testing 
Institute  validated)  software  is  MAP  3.0  or  TOP 
3.0  compatible.  The  ISO  software  from  Intel  is 
available  in  two  forms;  MAP  (layers  5-7),  or  iNA 
960  soltware  executes  on  any  Intel  processor 
(8086,  80186,  80286  or  80386).  Tho  MS-NET 
software  communicates  with  Intel's  iNA  960  ISO- 

complalnt  software. 

This  application  example  Is  based  on  a  smart  PC 
LAN  board,  The  PC  LAN  board  uses  the  standard 
MS-NET  software  and  provides  a  NETBIOS  Interface. 
Modifications  are  made  to  the  INA  960  software 
base  to  allow  the  incorporation  ot  the  IKGM-100 
module  Into  a  smart  LAN  design.  Figure  1  shows 
the  Implementation  ot  this  module. 

Hardware  Architecture 

Four  areas  need  to  be  addressed  In  the  hardware 
design.  These  tour  areas  are: 

-  Spilt  Internal  bus  design  using  the  IKGM- 
100  (Inline  design) 

•  Duplication  of  the  bus  interface  to  be 
compatible  with  PCUNK2 

-  Maintain  or  improve  system  performance. 

-  Maintain  software  compatibility. 
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The  overriding  architectural  design  criterion  was 
to  maintain  sofeware  compatibility  where 
possible,  In  order  to  fully  understand  the 
hardware  requirements,  each  of  these  areas  will 
be  reviewed. 


ETHERNET  LAN  USING  IKGM-100 


There  are  two  methods  that  can  be  used  in  a 
design  with  the  IKGM-100  Key  Generation  module. 
The  possible  methods  are  a  oo-processor  mode  and 
an  Inline  mode.  The  co-processor  mode  Is  for 
trusted  systems  where  the  module  Is  use  as  part 
of  the  communications  kernel.  The  trusted  system 
environment  controls  all  communications  and 
levels  of  access.  Hence  the  system  environment 
has  the  level  of  trust  necessary  for  the 
communications  traffic.  In  trusted  environments, 
there  Isn't  the  need  monitor  all  traffic  from  the 
computer  system  to  the  network. 

The  inline  mode  Is  used  for  systems  that  do  not 
provide  a  trusted  environment.  The  Inline 
implementation  blocks  un-authorize  access  from 
transferring  data  to  the  communications  medium. 
Hence  an  inline  design  need  not  concern  itself 
with  the  classification  of  the  user,  since 
classification  Is  a  function  of  the  key  access. 

In  all  cases,  the  iKGM-100  module  blocks  the  user 
access  Is  to  the  outside  world  for  clear  text. 

In  some  cases,  there  Is  a  need  to  transfer  clear 
text,  the  IKGM-100  management  facility  allows 
accountability  by  controlling  the  data  with 
bypass  features  of  the  module.  The  IKGM-100 
module  is  designed  In  such  a  way  that  the  level 
of  classification  Is  a  function  of  the  key 
initialization  process,  Typically,  with  out 
powor  supplied  to  the  IKGM-100  module,  the  device 
Is  viewed  as  controlled  cryptographic  product, 
that  meets  Type  I  applications.  Classification 
of  the  device  exists  once  the  system  Is 
initialized  with  its  key. 

The  inline  design  essentially  splits  the  bus 
separating  clear  text  (Red  side)  from  encrypted 
text  (BLACK  side)  with  the  iKGM-100  module.  In 
the  PC  design,  the  bus  split  Is  accomplished  on 
the  PC-controller  card  (figure  2).  The  bus  split 
allows  the  division  of  hardware  between  the 
Controller  card  and  the  Datalink  card.  The 
Controller  card  contains  the  iKGM-100  module. 

The  inline  design  does  not  allow  the  iKGM-100 
module  bus  access,  All  data  traffic  to  the 


datalink  card  must  flow  through  the  iKGM-100 
module.  The  CPU  on  the  controller  card  is  an 
Intel  S0386  with  an  integrated  protection 
architecture  and  the  appropriate  interface 
devices  to  the  iKGM-100  module. 

The  controller  card  design  has  enough  horsepower 
to  handle  the  secured  communications  software 
overhead,  and  the  iKGM-100  Interlace.  The 
addition  of  the  direct  memory  access  (DMA)  unit 
may  allow  the  use  of  a  less  expensive  CPU. 

However,  due  to  the  nature  of  the  hardware 
architecture,  a  CPU  with  a  built-in  protection 
architecture  is  key  to  this  design's  success. 

One  of  the  main  security  functions  of  the 
controller  card  Is  to  handle  the  key 
manipulations  to/from  the  IKGM-100  module,  and  to 
control  any  unauthorized  access  to  the  module. 

The  80386  and  80286  central  processing  units 
(CPU)  meet  protected  code  requirements,  providing 
Instruction  trap  faults  when  illegal  operations 
are  performed. 

The  datalink  monitor  card  contains  the  ethemet 
component  (82586)  and  a  12Mhz  80186  device.  This 
board  Is  designed  to  handle  the  reception  and 
transmission  of  data  packets  from  the  Ethernet 
network  and  the  IKGM-100  device.  There  isn't  a 
need  for  a  fast  CPU  at  this  end,  only  for  a  CPU 
that  can  handle  the  network  layer  and  routing 
overhead.  The  spilt  bus  design  using  the  iKGM- 
100  allows  the  ideal  separation  ol  processors  on 
the  BLACK  and  tho  RED  side. 

Each  of  the  CPU  designs  contain  RAM  and  EPROM. 
The  control  software  may  be  ROM  resident  or  RAM 
resident.  The  hardware  design  can  support  both 
situations,  but  do  to  the  environment,  the 
software  is  Implemented  in  ROM.  Figure  2  shows 
the  proposed  implementation  using  the  iKGM-100 
module  In  a  split  PC  board  design. 

SECURED  COMMUNICATIONS 


3ATA  Li,,«  ENGINE 


TEEACHE  .  CONTAOllCH 


SPLIT  BUS  LAN  DESIGN  WITH  IKGM-100 
FIGURE  2 


System  Performance: 

The  system  performance  must  appear  to  the  user  as 
if  the  iKGM-100  module  does  not  exist.  The  dual 
processor  design  allows  for  the  maximum  system 
performance.  The  dual  processor  Implementation 
uses  an  Intel  80386  at  the  RED  side  to  handle  bus 
communications,  IKGM-100  management  and  transport 
packet  redirection,  The  BLACK  side  contains  the 
12Mhz  80186  processor.  If  needed  the  3LACK  side 
processor  could  be  changed  to  an  Intel  80286  or 
80386  which  is  object  code  compatible  with  the 
80186  device. 

One  of  the  additional  features  of  using  an  Intel 
60386  Is  the  capability  to  Isolated  security 
features  from  the  network  applications  code.  In 
any  endorsement  activity,  the  speed  of  achieving 
endorsement  is  a  function  of  Isolating  the  iKGM- 
100  access  code.  The  Intel  80386  CPU  allows  high 
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performance  and  a  protected  architecture  that 
Isolates  application  code,  and  Improves  the 
overall  efficiency  of  the  communications  system. 

Software  Compatibility; 

The  main  Issue  for  software  compatibility  Is  to 
support  MS-NET,  NETBIOS  and  ISO  standard 
software.  Figure  3  contains  an  IBM  PC  compatible 
ethernet  communications  card  s  (PCUNK2)  software 
architecture.  The  PCUNK2  architecture  allows 
applications  programs  to  communicate 
transparently  with  a  network  based  communications 
server.  This  means  that  any  software  program 
that  uses  NETBIOS  or  MS-NET  on  PCLINK2  may 
execute  across  the  network  using  ISO  standard 
communications  protocols. 

The  PCLINK2  architecture  will  be  the  basis  for 
the  secured  data  network  design.  Using  the 
PCUNK  architecture,  current  directions  in 
communications  security  places  the  data 
communications  encryption  engine  below  ISO 
transport  layer.  By  using  a  software 
architecture  as  shown,  user  applications  are 
guaranteed  ICO  %  software  compatibility.  Hence, 
any  hardware  changes  to  the  IBM-PC  environment 
would  be  restricted  to  the  front  end  processor, 

The  user  would  be  able  to  access  any  off-the- 
shelf  software  packages  without  affecting  the 
security  capability  of  the  secured  personal 
computer. 


PCLINK  SW  R3.0  Architecture 


FIGURE  3 


The  software  compatibility  may  be  simply 
redefined  as  a  hardware  communications 
architecture  that  does  not  affect  any  PC  software 
application  packages.  The  split  bus  design  with 
the  IKGM-100  has  successfully  Isolated  the 
hardware  architecture  from  the  applications 
software. 

Software  Architecture 

The  major  design  effort  required  is  In  the 
communications  software,  Intel's  Networking 
Architecture  (INA)  allows  a  simplified  approach. 

The  iNA  design  is  around  a  kernel,  with  separate 
protocol  units  pertorming  the  transport  and  data 
link  functions.  Figure  4  shows  the  protocol 
environment  of  INA  060,  a  subset  of  INA,  iNA  is 
the  key  software  design  architecture  required  to 
Implement  a  secured  networked  workstation. 

The  objectives  In  the  software  Implementation  of 
the  secured  network  are  as  follows: 

maintain  programmatic  Interface  to 

MS-NET  and  NETBIOS. 


-  minimize  software  that  Interfaces  to 
the  IKGM-100 

-  minimize  software  required  for 
endorsement 

-  provide  a  platform  for  SDNS 
development 

-  absolutely  no  host  operating  system 
changes 

Each  of  the  above  objectives  require  that  the 
communications  software  be  flexible;  to  meet  the 
secured  data  network  requirements  for  today  and 
tomorrow.  In  order  to  fully  understand  the 
Implication  of  the  design,  each  area  will  be 
reviewed. 


INA  960  PROTOCOL  MODEL 
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FIGURE  4 


Programmatic.  Interface: 

One  of  the  few  areas  that  users  tend  to  ignore  is 
the  maintenance  of  the  programmatic  Interlace. 

All  MS-NET,  NETBIOS  and  LAN-Manager 
Implementations  are  fully  compatible  with  this 
design.  The  application  software  must  be  able  to 
execute  on  the  system  without  any  changes.  For 
example,  In  a  networking  environment,  the  DBASE 
III  or  Word  Perfect  software  packages  must  be 
able  to  make  NETBIOS  calls,  and  access  data 
without  any  problems.  In  order  to  accomplish 
this,  the  programmatic  Interface  must  remain 
unchanged. 

Intel's  PCUNK2  Release  3  software  allows  this 
capability.  The  user  will  have  full  access  to 
all  of  the  NETBIOS  features.  This  means  that  the 
IBM-PC  networks  program  must  be  able  to  execute 
without  any  errors.  Hence,  the  user  will  be  able 
to  use  any  applications  software  from  the  user 
community. 


Software  required  for  the  IKGM-100: 

The  INA  960  architecture  allows  the  creation  of 
user  tasks  to  perform  functions.  Figure  5  shows 
the  INA  960  architecture.  In  this  diagram,  the 
INA  960  software  was  split.  One  processor 
handles  the  transport  layer,  the  other  processor 
handles  the  network  layer.  The  IKGM-100  module 
sits  between  the  RED  and  BLACK  sides. 

The  software  required  to  communicate  to  the  IKGM- 
100  may  be  separated  into  two  different  tasks. 

One  task,  on  the  RED  side,  handles  all  of  the 
communications  to  the  modules  as  well  as  key 
Initiation  and  management.  The  Applications 
Programmatic  Executive  (APEX)  task  coexists  with 
INA  960  and  performs  any  needed  communications  to 
the  iKGM-100  module.  The  RED  side  task  Is 
simplified,  handling  only  the  data  Input  to  the 
IKGM-tOO  module.  In  the  software  design,  the 
80386  CPU  ring  protection  module  Is  used  to 
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further  segment  the  user  access,  The  actual 
network  communications  software  on  the  RED  side 
is  contained  in  the  lowest  protection  level  of 
the  processor.  This  access  level  grants  all 
users  access  to  the  communications  facilities. 

The  highest  level  of  protection  is  given  to  the 
iKGM-100  management  functions.  In  figure  5,  the 
level  0  privilege  functions  are  shown  on  the  RED 
side,  and  level  4  privilege  functions  are  given 
to  the  ISO  communications  software  (Intel's  iNA 
960). 

INA360  Architecture  with  IKGM-IOO 


FIGURE  5 

The  second  task,  located  on  the  BLACK  side,  is 
responsible  for  transferring  information  from  the 
iKGM-100  module  to  the  network  layer.  The  BLACK 
side  task  is  also  responsible  for  handling  any 
re-synchronization  with  the  iKGM-100  module. 

This  entails  the  transfer  of  network  management 
information,  encrypted  keys  and  data  received 
from  the  network  layer.  The  BLACK  side  task  does 
not  need  to  have  the  same  level  of  trust  do  to 
the  structure  of  the  Inline  design.  An  example 
of  the  software  architecture  Is  shown  in  figure 


The  final  area  is  the  issue  of  Key  management. 

The  structure  of  iNA  960  allows  different 
application  tasks  to  exist.  The  key  management 
task  executes  as  a  function  under  the  APEX 
kernel,  in  the  80386  privilege  level  0  and 
outside  of  the  ISO  protocol  as  much  as  possible. 

A  simplified  view  shows  key  management  as  a 
function  of  network  management. 

Endorsement: 

The  major  advantage  of  using  iNA  960  is  to 
minimize  the  endorsement  process  for  the  secured 
LAN  product.  The  COMSEC  boundary,  (shown  In 
figure  5),  limits  the  software  required  for 
endorsement  to  the  RED  and  BLACK  tasks.  The  RED 
and  BLACK  tasks  are  structured  to  handle  iKGM-100 
management  and  various  encryption  management 
utilities.  Due  to  the  communications  structure 
of  iNA  960,  all  communications  protocols  are 
limited  to  distinct  task  architecture.  Hence, 
the  only  endorsement  that  is  required  is  for  the 
Interface  software  to  the  iKGM-100  module.  This 
is  the  case  duo  to  the  development  of  the  IKGM- 
100  as  an  endorsed  NSA  CCEP  device. 

in  contrast,  if  a  non  CCEP  module  Is  used,  the 
COMSEC  boundary  may  be  extended  to  the  entire 
software  task  structure  Identified  in  figure  4. 

As  a  result  of  the  new  COMSEC  boundary  being 
defined,  the  endorsement  process  will  be  longer. 

For  example,  if  a  product  like  INA  960  was  used 
on  a  module  that  is  Qgl  endorsed  by  the  CCEP 
program,  the  complete  ISO  protocol  Implementation 


and  the  hardware  performing  the  data  encryption 
would  need  to  be  endorsed.  As  a  point  of 
reference,  INA  960  contains  20  person  years  of 
code  development.  (18,000  lines  of  source  code). 

In  general,  a  design  that  has  not  been  evaluated 
to  the  rigorous  security  analysis,  must 
eventually  be  evaluated  to  that  standard.  The 
current  evaluation  standard  Is  a  time  consuming 
process  and  any  error  noted  will  require  a 
redesign  plus  reevaluation  of  the  product. 

Potential  products  submitted  to  NSA  that  do  not 
conform  to  the  CCEP  standards,  may  take  up  to  10 
years  to  receive  the  officially  NSA  endorsement. 


Secured  Network  Platform: 

The  secured  network  communications  architecture 
requires  flexibility.  The  goal  of  the  secured 
network  architecture  Is  to  support  current 
communications  technology  and  the  next  generation 
systems.  In  order  to  meet  the  flexibility 
requirements,  the  software  architecture  must 
allows  the  testing  of  different  communications 
hypotheses.  Flexibility  requires  that  the 
encryption  module  must  be  configurable  to  support 
today's  communications  needs  as  well  as 
tomortow's.  Intel's  products,  iNA  960  and  the 
IKGM-100  key  generation  module  are  extremely 
flexible  In  their  design.  INA  960  allows 
multiple  user  tasks  to  interact  with  the  software 
protocols.  The  IKGM-100  supports  multiple  data 
encryption  schemes  for  greater  software 
flexibility. 

The  secured  data  network  Implementation  needs  to 
be  able  to  create  a  management  task,  (as  shown  in 
figure  5)  to  perform  COMSEC  functions.  The  ISO 
software  product,  iNA  960,  allows  the  user  to 
create  multiple  management  tasks.  In  the 
creation  of  these  tasks,  the  user  may  Integrate 
multiple  applications  based  on  transport  address 
ID's.  Likewise  the  network  service  access  ID's 
may  be  U3ed  on  the  BLACK  side  as  well.  In 
addition  to  communicating  to  the  protocol 
modules,  the  secured  network  implementation 
architecture  needs  to  use  a  dual  tasking 
architecture.  In  the  COMSEC  boundary,  one  APEX 
task  (transport  and  network  management)  can 
execute  on  the  RED  side  and  the  other  on  the 
BLACK  side  (network  and  datalink). 

The  use  of  iNA  960  together  with  the  iKGM-100 
module  allows  maximum  flexibility.  Any  secured 
network  Implementation  may  be  readily  prototype, 
tested  and  put  into  production,  INA  960  and 
IKGM-100  meet  the  needs  ot  any  secured 
communications  development. 

No  Host  Operating  System  Changes: 

The  major  objective  of  the  software  design  was  to 
not  to  change  the  host  operating  system  MS-DOS. 

All  additional  commands  necessary  to  initialize 
the  communications  module  may  take  place  as 
application  software  running  under  MS-DOS  or 
Wlndows-386.  The  application  Implementation 
described  allows  the  user  to  purchase  an  off-the- 
shelf  personal  computer,  with  the  COMSEC  module, 
and  connect  It  Into  the  network.  The  goals  In 
this  design  are  simplicity  and  flexibility, 

Since  the  communications  software  Is  restricted 
to  the  intelligent  LAN  board,  all  software 
changes  are  contained  on  the  COMSEC  module.  Off- 
the-shelf  application  software  packages  may  be 
used  to  access  network  Information.  The 
applications  would  only  see  the  MS-NET  or  NETBIOS 
interface  (figure  3),  not  the  IKGM-100  module. 
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Summary 

Overall,  a  design  with  iNA  960  and  the  iKGM-100 
allows  the  greatest  flexibility  in  a  secured  data 
network.  Due  to  the  iNA  960  internal  design, 
splitting  the  communications  software  can  be 
easily  accomplished,  The  INA  960  software 
executes  under  an  APEX  kernel.  The  transport  and 
network  interfaces  are  isolated  to  a  few 
procedural  calls  (buffers,  information,  and 
packets  etc.).  These  procedural  calls  may  be 
easily  broken  down  into  their  individual  parts, 
specific  to  the  communications  Implementation, 

The  software  environment  of  the  PC  would  remain 
unchanged.  There  would  be  new  utilities  for  key 
management,  but  the  base  operating  system  would 
not  be  touched.  This  Is  extremely  critical.  The 
user  that  would  execute  software  on  this 
workstation  would  be  able  to  use  any  off-the- 
shelf  MS-DOS  product.  Hence,  the  secured  network 
objectives  could  be  reached  with  an  architecture 
similar  to  PCLINK2  which  would  incorporate  the 
iKGM-100  module:  that  Is  a  Secured  PC  LAN  card, 
easy  to  use,  with  minimum  performance  Iosg,  and  a 
cost  effective  solution. 

^  IKGM-100,  iNA  960  and  PCLINK2  are  a  trademark 

of  Intel  Corporation. 

MS-NET  is  a  trademark  of  Microsoft  Corporation 


3  The  iKGM-100  Advanced  Key  Generation  Module, 
In  addition  to  providing  an  NSA  developed 
encryption/unencryptlon  capability,  also  has  a 
robust  set  of  Agency  endorsed  Security 
Features.  These  features  are  outlined  below: 


Internal  Storage  -  The  iKGM-100  has 
volatile  storage  for  up  to  255  keys. 
Tins  feature  allows  simultaneous 
connections  in  supporting  various  kev 
management  schemes. 


Key  External  Storage  •  In  addition  to 
having  storage  on-board  the  IKGM-100 
allows  external  storage  of  the  keys  in  ’ 
the  host.  This  feature  allows  keys  to  be 
stored  in  the  host  for  later  use  As 
with  key  storage  this  feature  is  useful 
in  key  management  schemes. 

Remake  Keys  •  The  IKGM-100  has  the 
ability  to  electronically  distributes 
Initialize  vectors  to  remote  users.  This 
feature  Is  useful  in  key  management  of 
geographically  dispersed  environments. 

CiK  Support  -  Support  for  a  "Crypto 

inn  °nT^ey.  is  avaiiaa!e  on  the  IKGM- 
100  This  feature  Is  particularly  useful 
In  the  workstation  environment.  It 
allows  a  COMSEC  environment  to  be  locks 
and  unlocked  cryptologlcally. 

High  Bandwidth  -  The  IKGM-100  has  6 
cryptographic  operating  modes  plus  a 
Message  Authentication  Code  (MAC)  mode 

Thfl  *hrupVt  ls  7  Megablls/second 

i  he  iKGM-loo  transfer  rate  Is  based  on 

On!,i:0^,09riphic  moda  setectod,  In  the 
application  discussed  In  this  paper  the 
cryptographic  mode  selected  will  operate 
at  2.87  Megabits/second. 


Alarms  -  The  iKGM-100  provides  security 
protection  in  the  form  of  internal  alarms 
to  detect  intrusion  and  Internal 
failures.  These  functions  can  be 
utilized  in  various  methods  to  insure 
system  security. 

Controlled  Bypass  -  a  particularly  useful 

feature  incorporated  into  the  design  of 
the  iKGM-100  is  "controlled  bypass”. 

This  feature  is  used  to  bypass  clear  text 
such  as  header  information  or  control 
characters. 

All  of  the  Features  discussed  above  have  been 
endorsed  by  the  National  Security  Agency  for 
all  levels  of  classified  communication.  By 
utilizing  the  iKGM-100  In  COMSEC  designs  a 
majority  of  the  security  design  criteria  have 
been  approved  as  implemented.  This  is  the 
major  reason  for  choosing  the  IKGM-100  for  the 
Secured  PC  LAN  controller. 

*  The  currant  implementation  of  the  Tepache 
module  doss  not  support  a  firefly  exchange. 

This  capability  is  being  reviewed  for  the  next 
generation  module,  The  goal  of  the  design  is 
to  allow  firefly  exchanges  to  be  processed  in 
less  than  a  second. 

5  Xenix  Is  a  trademark  of  Microsoft  Corporation. 
Unix  is  a  trademark  of  AT&T  Corporation 
MS-DOS  Is  a  trademark  of  Microsoft  Corporation. 
IRMX  is  a  trademark  of  Intel  Corporation. 
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ABSTRACT 


The  Gamini  family  of  high  assurance  trusted 
computing  base  ( TCB )  products  is  described. 
The  manner  in  which  these  TCB  products, 
which  are  designed  to  be  Class  Al,  address 
different  operational  requirements  is 
addressed.  A  selected  list  of  currant 
applications  and  projects  in  which  the 
currently  available  products  are  being  used 
is  presented,  in  addition  to  a  description 
of  several  research  projects  that 
illustrate  the  product's  current  potential 
and  future  directions. 


INTRODUCTION 

The  purpose  of  this  paper  is  to  provide  an 
overview  of  the  GEmini  Multiprocessing 
Secure  Operating  System  (GEMSOS)  product 
line,  which  includes  a  variety  of  hardware 
and  system  software  components.  The  major 
components  offered  commercial lv  are  a 
family  oi  hardware  systems  in  a  variety  of 
configurations,  a  high-performance 
multiprogrammoble,  multiprocessor  security 
kernel  [1]  to  control^the  hardware  systems, 
and  a  TCB  designed  to  utaet  Class  Al  that 
includes  the  security  kernel  and  hardware 
systems.  This  family  of  products  has  been 
under  developmental  evaluation  for  several 
years  as  the  design  and  implementation  has 
proceeded.  Advance  versions  of  the 
hardware  base  and  secu-ity  kernel  have  been 
available  as  commercial,  off-the-shelf 
products  for  several  years  and  have  been 
selected  for  incorporation  as  part  of 
several  development  projects  that  will  be 
independently  evaluated  as  Clas3  B3  or  Al 
systems.  We  anticipate  entering  the  formal 
evaluation  process  with  the  entire  TCB 
within  a  few  months,  with  completion  of  a 
successful  formal  evaluation  later  in  1989. 

As  for  any  family  of  ccmmerical  products, 
key  architectural  characteristics  common  to 
the  entire  family  can  be  discerned  that 
reflect  the  beliefs  of  the  designers  as  to 
what  will  be  needed  for  a  commercially 
viable  system.  In  the  case  of  GEMSOS,  an 
emphasis  has  been  placed  on  the  use  of  an 
identical  security  kernel  throughout  the 
current  and  future  product  line,  the 
achievement,  of  a  low  cost/performance  ratio 
using  a  multi-microprocessor  hybrid  CPU 
architecture,  the  careful  structuring  of 
the  TCB  into  separable,  and  independently 
evaluatable  TCB  subsets  [2]  enforcing 
orthogonal  security  policy  components,  and 
the  use,  wherever  feasible,  of  industry- 
standard  components  and  interface 
specifications.  The  result  is  a  family  of 


highly-assured,  trusted  components  that  can 
be  used  as  stand-alone  systems  or  as  parts 
of  more  complicated  trusted  systems,  or 
which  can  be  modified  or  extended  by  third 
party  vendors  with  a  minimum  impact  on  re- 
evaluation.  (In  particular,  the  security 
kernel  itself  rarely  needs  to  be  modified, 
and  can  be  treated  au  a  high-assurance 
"sealed  unit".)  We  call  this  concept  an 
"open  security  architecture". 

Because  of  the  importance  cf  the  open 
security  architecture  for  the  design  of 
GEMSOS,  the  next  section  discusses  our 
reasons  for  believing  that  the  concept  is 
appropriate  for  a  commercial  product.  We 
then  present  a  technical  overview  of  the 
GEMSOS  architecture,  followed  by  a  selected 
list  of  applications  and  projects  in  which 
the  security  kernel  has  already  been  used. 
This  is  followed  by  a  description  of 
several  research  projects  that  indicate 
more  advanced  intended  applications  for  the 
GEMSOS  TCB,  emphasizing  projects  intended 
to  provide  some  measure  of  compatibility 
with  existing  standard  (non-secure)  system 
interfaces. 

PRODUCT  STRATEGY 

We  view  our  corporation  as  a  supplier  of 
primary  high-assurance  (Class  B3  and  Al) 
components  to  system  integrators  requiring 
such  components  to  meet  the  needs  of  their 
end-users.  We  believe  that  for  a  viable 
high-assurance  TCB  market  to  exist,  it  must 
be  based  upon  the  shared  use  of  the 
critical  technical  component  required  for 
any  high-assurance  system,  a  security 
kernel.  In  order  to  be  useful  as  the  basis 
for  a  self-sustaining  vendor/user 
community,  that  security  kernel  must 
support  a  wide  range  of  applications,  be 
cost-effective  from  the  standpoint  of 
performance,  support  the  construction  of 
distributed  and  networked  systems,  and  be 
available  to,  and  usable  by,  value-added 
and  third  party  commercial  vendors  so  that 
the  creation  and  maintenance  of  a  large 
body  of  usable  application  software  can  be 
fostered. 

Our  overall  strategy,  then,  for 
participating  in  the  market  for  high- 
assurance  systems  has  been  tc  first, 
develop  a  security  kernel  with  the  required 
technical  and  commercial  characteristics; 
second,  to  build  a  TCB  based  upon  this 
kernel  and  complete  its  evaluation  at  Class 
Al  of  the  Trusted  Computing  System 
Evaluation  Criteria  [3],  and  third,  to 
footer  its  utilization  by  as  wide  a  variety 
of  vendors,  system  integrators,  and 
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software  developers  as  possible.  We  have 
completed  the  first  task,  are  engaged  in 
the  second,  and  intend  to  continue  the 
third  as  vigorously  as  possible. 

Because  our  security  kernel  is  the  key 
technology  around  which  the  remainder  of 
our  product  and  most  of  our  technical 
activities  are  organized,  it  is  worth 
taking  a  broad  look  at  its  design 
characteristics  before  proceeding  into  a 
more  detailed  discussion  of  our  activities. 
The  GEMSOS  security  kernel  SP  (which 
includes  the  hardware  as  well  as  a  software 
component)  is: 

•  always  invoked,  (that  is,  cannot  be 
bypassed  by  any  non-kernel  programs  or 
by  users ) ; 

•  tamperproof, 

a  small  enough,  and  well-structured 

enough,  to  support  evaluation  at  Class 
Al; 

•  built,  for  the  most  part,  from 
industry  standard  hardware  components 
(Intel  80286/80386  processors, 

Multibus  I  backplane  with  third-party 
circuit  boards,  IBM  PC/AT  hardware, 
etc.  ); 

•  supports,  as  feasible,  industry 
standard  interfaces  (RS-232,  Ethernet, 
X.25,  EGA,  Centronix,  etc.  ); 

•  is,  therefore,  portable; 

•  organizes  the  remainder  of  the 
software  system  into  eight 

, hierarchical  protection  rings  which 
makes  it  extensible,  (i.e.,  TCB 
subsets  enforcing  additional  access 
control  policies  and  supporting 
policies  can  bo  erected  "on  top"); 

•  has  a  low  cost-performance  ratio 
(because  it  utilizes  inexpensive 
microprocessors ) ; 

•  has  flexible  capacity  with  a  high 
maximum  performance  (because  it 
utilizes  up  to  eight  processors  in  a 
proprietary  architecture  that  reduces 
bus  traffic  substantially); 

•  is  accompanied  by  a  UNIX  *  programming 
environment  providing  the  basic  tools 
needed  to  program  the  system  using 
modern  high-level  languages  (Pascal, 
C); 

*•  and,  last  but  not  least,  is  done. 

(The  security  kernel  has  been 
available  and  delivered  as  a 
commercial,  off-the-shelf  product,  for 
over  two  years.) 


*  UNIX  is  a  trademark  of  AT&T 


The  complete  GEMSOS  TCB,  which  is  currently 
under  development,  is,  of  course,  based  on 
the  GEMSOS  security  kernel .  Our  product 
line,  which  includes  hardware  components 
and  the  security  kernel,  and  soon  will 
include  the  remainder  of  the  TCB  as  well, 
is  designed  to  support  four  major 
categories  of  use: 

•  a  dedicated  application  market, 
comprising  custom  applications  written 
to  serve  a  specific  end-user 
installation  or  requirement,  (i.e., 
for  a  sponsored  development  project), 

•  a  value  added  market,  comprising 
customers  who  wish  to  add  significant 
software  applications  (e.g.,  message 
handling  systems,  file  servers, 
communications  software,  DBMS 
software)  as  secure  applications  to 
the  TCB,  without  disturbing  the 
internals  of  the  TCB  in  any  way; 

•  a  second  source  market,  comprising 
customers  who  wish  to  market  their  own 
TCB  but  avoid  the  cost  of  developing 
their  own  security  kernel. 

•  an  embedded  component  market, 
comprising  customers  who  need  highly- 
assured  components  for  larger  systems 
applications  (e.g.,  network 
components) . 

All  of  these  potential  markets  have 
differing  needs:  the  one  thing  they  have 
in  common  i3  the  need  for  a  highly-assured 
security  kernel  whose  development  expense 
is  already  being  amortized. 

The  dedicated  application  market  needs  a 
wide  range  of  configuration  and  performance 
options,  so  that  the  delivered  system  can 
be  tailored  to  the  precise  needs  of  the  end 
application.  In  addition,  a  custom 
application  typically  will  require 
customized  discretionary,  identification, 
authentication,  or  audit  policies,  or  a 
combination  of  these.  The  GEMSOS  kernel  is 
therefore  designed  to  support  a  wide  range 
of  hardware  and  peripheral  options  in  both 
loosely-coupled  and  tightly-coupled 
configurations,  and  the  GEMSOS  TCB  is 
composed  of  subsets  so  that  individual 
policy  components  can  be  modified  without 
disturbing  the  software  or  evaluation 
evidence  already  available  for  the  rest. 

The  value-add- d  market  needs  a  widely-used 
equipment  baso  with  a  stable  interface  so 
that  there  is  a  viable  market  for  third- 
party  applications.  A  secondary  (but 
often,  important)  need  is  the  ability  to 
bypass  general-purpose  operating  system 
functions  in  order  to  attain  performance 
goals.  By  making  the  details  of  the  TCB 
interface  available  to  third-party 
developers,  both  of  these  needs  are 
fostered:  this  is  the  "oper,  software 

architecture"  policy  which  has  been  widely 
successful  in  the  microcomputer  industry. 
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The  dubious  benefit  of  "locking  in"  end 
users  to  a  sole  supplier  (by  concealing  the 
details  of  important  system  interfaces)  is 
foregone  in  favor  of  fostering  the 
development  of  third-party  add-ons  and 
applications  in  order  to  build  a  self- 
sufficient  community  of  users  and  vendors. 

The  second  source  market  is  served  by 
making  our  technology  available  under 
license,  if,  for  instance,  a  vendor 
believes  that  there  is  a  marketable  "better 
way"  to  provide  discretionary  controls  than 
we  supply,  or  can  beat  our  price,  it  is  at 
least  straightforward  to  procure  the 
requisite  OEM  license  in  order  to  use  the 
security  kernel  as  the  basis  for  a 
competitive  TCB ,  Licenses  for  the 
utilization  of  our  technology  are  available 
under  a  variety  of  different  business 
arrangements,  including  source  code 
licenses  for  the  security  kernel  itself. 

Finally,  the  embedded  component  market  is 
served  by  providing  a  high-performance 
security  kernel  based  on  commonly  available 
microprocessor  technology  that  can  be 
ported  to  new  hardware  environments.  The 
intrinsic  portability  of  the  kernel  has 
already  been  demonstrated  by  porting  it  to 
the  IBM  PC/AT  *  hardware  environment,  which 
proved  to  be  a  relatively  inexpensive 
effort.  Should  the  end-user  community 
provide  sufficient  demand  for  a  lightweight 
(aerospace)  or  tempested  enclosure,  for 
example,  the  technology  could  be  licensed 
to  a  prime  contractor  or  commercial  vendor 
and  ported  to  a  "design  to  specification" 
enclosure. 

PRODUCT  DESCRIPTION 

The  Gemini  family  of  computer  systems 
provides  a  powerful  combination  of 
multilevel  security  and  multiprocessing 
capabilities.  The  adaptability  of  GEMSOS 
makes  the  Gemini  systems  attractive  as  a 
trusted  base  for  a  wide  range  of  concurrent 
and  real-time  computing  applications 
including  command  and  control, 
communication,  intelligence,  weapons, 
networks,  and  office  automation  end  uses. 

Within  each  enclosure,  tightly  coupled 
multiple  microcomputers  communicate  through 
shared  memory  segments  to  provide  high- 
throughput  performance.  Up  to  8  Intel 
80286  or  80386  based  microcomputers  can  be 
served  by  the  same  Multibus  to  provide  the 
required  amount  of  processing  power.  GEMSOS 
avoids  bus  contention  by  locating  data  and 
code  segments  in  local  memory  of  each 
microcomputer  whenever  possible. 

Between  loosely  coupled  enclosures, 
processes  communicate  via  ethernet,  X.25, 
or  RS-232  based  multilevel  channels. 


*  PC/AT  is  a  trademark  of  IBM. 


GEMSOS  Security  Kernel 

The  GEMSOS  security  kernel  supports 
multiprocessing  as  well  as 
multiprogramming.  The  kernel  virtualizes 
all  system  resources,  providing  service 
calls  for  the  required  process  management, 
segment  management  and  device  management. 

The  GEMSOS  security  kernel  enforces  a 
label-based  Mandatory  Access  Control 
policy.  The  commercial ly-available  GEMSOS 
kernel  supports  both  secrecy  and  integrity 
access  class  components,  each  with  16 
hierarchical  levels.  GEMSOS  also  supports 
64  non-hierarchical  secrecy  categories  and 
32  non-hierarchical  integrity  categories. 
For  licensed  or  OEM  systems,  the  non¬ 
discretionary  security  module  of  the 
Security  Kernel  can  be  customized  to 
support  any  lattice  security  policy, 
including  Clark-Wilson  [4],  trusted 
pipelines  [5],  or  policies  needing  multiple 
secrecy  and/or  integrity  hierarchies  or 
extended  numbers  of  non-hierarchical 
categories. 

Hardware  Configurations 

A  "Gemini  System",  in  the  most  general 
case,  consists  of  multiple  loosely-coupled 
hardware  enclosures.  A  typical 
configuration  might  consist  of  one  or  more 
Gemini  central  host  processors,  together 
with  as  many  secure  workstations  as 
required,  communicating  via  Ethernet  or 
RS-232  communications  channels.  Where  the 
cost  of  an  "intelligent"  secure  workstation 
could  not  bo  justified,  a  smaller  Gemini 
host  configured  as  a  terminal  concentrator 
could  be  utilized  to  support  communications 
between  multiple  "dumb"  terminals  and  the 
central  hosts.  A  low-end,  multi-user 
configuration  might  consist  of  a  slnglo 
Gemini  central  host,  . ccessed  by  means  of 
"dumb"  terminals  connected  directly  to  the 
host  processor. 

A  single  Gemini  enclosure  is  either  a 
Multibus-based,  tight.ly-coupled  host 
processor,  or  a  MLS-AT  workstation,  which 
is  the  GEMSOS  configuration  that  executes 
on  PC/ATs  and  selected  compatabies. 

The  Multibus-based  systems  are  designed  to 
offer  a  wide  range  of  configurable  options: 
three  enclosure  sizes  are  offered,  offering 
support  for  from  one  to  eight  processors 
(Intel  80286  or  Intel  80386).  Together 
with  memory  options,  the  throughput  rates 
available  span  a  range  of  from  0.5  to  24 
Million  Instructions  Per  Second.  A  variety 
of  secondary  storage  and  I/O  options  are 
currently  implemented.  An  "open 
architecture"  approach  has  been  designed 
into  the  system  from  the  beginning: 
industry-standard  components  and  non¬ 
proprietary  Multibus  I  boards  allow 
customized  and  tailored  applications  to  be 
considered.  The  single  Gemini  proprietary 
board  for  the  Multibus  system  is  the  Gemini 
System  Controller,  which  uses  proprietary 
technology  to  enhance  bus  performance  as 
well  as  providing  certain  peripheral 
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devices  (e.g.,  hardware  DES  encryption 
support)  required  by  the  TCB. 

The  Gemini  Multibus  I  systems  provide 
access  to  supported  peripherals  through 
(possibly  tailored)  third-party  interface 
boards  directly  connected  into  the 
Multibus.  Under  GEMSOS  control, 
microcomputers  share  all  devices  interfaced 
to  the  Multibus.  The  system  supports 
various  combinations  of  hard  and  floppy 
disks  as  well  as  streaming  and  half-inch, 
9-traok  tape.  Non-volatile  memory  is 
available  for  "core  resident"  applications. 
Additional  devices  include  8-port  RS-232 
serial  I/O  cards,  ethernet  and  HDLC.  Each 
Gemini  system  includes  a  real-time  clock 
with  battery,  a  data  encryption  device 
using  the  standard  NES-DES  algorithm,  and  a 
system-unique  identifier.  The  Bystem  also 
contains  battery  backed  up  CMOS  for  storing 
operator  passwords  and  encryption  keys. 
Business  arrangements  are  available  for 
technology  licensees  to  add  application- 
specific  device  drivers  to  the  system!  the 
range  of  commercially  available  device 
drivers  supported  by  the  kernel  is,  of 
course,  continually  expanding  as  Gemini 
adds  device  drivers  to  the  repertoire  of 
supported  interfaces.  The  TCB  and  kernel 
device  drivers  are  typically  low-level  (as 
required  by  a  "minimized"  TCB  architecture 
for  Class  D3  and  above). 

Each  single-board  CPU  includes  local  memory 
(allocated  and  controlled  by  GEMSOS)  as 
well  as  a  bus  interface  unit,  and  several 
local  I/O  ports.  GEMSOS  virtualizes  the 
hardware  configuration  by  making  the 
allocation  of  local  and  global  memory  to 
segments  transparent  to  applications:  it 
is  also  relatively  straightforward  to 
construct  mul tiprogrammed  applications  that 
are  independent  of  the  number  of  processors 
available  as  well.  Inter-procees 
synchronization  is  identical  for  processes 
executing  on  the  same  processor  and 
processes  allocated  to  different 
processors.  The  TCB  supports  the  creation 
of  remote  processes  (in  a  different 
enclosure)  with  the  same  mandatory  and 
discretionary  attributes  as  the  creating 
process  in  order  to  support  distributed 
Applications  without  impacting  the  validity 
of  the  system  security  controls. 

Gemini's  family  of  TCB  products  includes  a 
MLS  AT  Workstation,  which  is  a 
configuration  of  GFMSOS  that  executes  on 
IBM  PC/AT  hardware  (and  selected 
compatibles).  The  intended  use  of  this 
configuration  is  to  provide  a  low-cort 
alternative  where  a  Becure,  "intelligent" 
workstation  is  required  by  a  system 
architecture.  Although  the  specific  I/O 
devices  available  at  the  workstations 
differ  in  detail  from  those  available  for  a 
Multibus  I  enclosure,  in  all  other  respects 
the  MLS  AT  Workstation  is  simply  a  single¬ 
processor  GEMSOS  system  at  the  programmer's 
interface.  This  GEMSOS  configuration 
includes  support  for  the  standard  Enhanced 
Graphics  Adapter  (EGA),  keyboard,  serial 
I/O  ports  and  the  Centronix  parallel 


printer  port. 

NON-KERNEL  TCB  DEVELOPMENT 

Gemini  is  currently  implementing  the  GEMSOS 
non-kernel  TCB  elements,  which  include 
discretionary  access  controls, 
authentication,  security  administrator 
support,  audit  and  support  for  inter- 
enclosure  communications  over  multilevel 
channels. 

Multi-ring  Architecture 

The  extensible  nature  of  the  GEMSOS 
Security  Kernel  provides  designers  groat 
flexibility  in  the  design  and 
implementation  of  trusted  computing  base 
capabilities  on  top  of  the  kernel  [6]. 
Gemini  has  separated  the  non-kernel  TCB 
functions  into  five  distinct  protection 
domains  (rings)  [7].  In  addition  to  the 
obvious  "least  privilege"  benefits,  this 
approach  allows  Gemini  to  offer  customers 
the  ability  to  tailor  specific  non-kernel 
TCB  functions  with  minimum  impact  on  the 
basiB  of  evaluation  for  the  functions 
allocated  to  other  rings.  In  particular, 
the  basis  for  evaluation  of  the  most 
demanding  component  of  a  high-assurance 
TCB,  the  security  kernel,  is  completely 
preserved.  The  intended  use  of  this 
architecture  is  to  support  the  capability 
to  tailor  discretionary,  identification, 
authentication,  and  audit  functions  to 
specific  installations  or  applications 
(e.g.,  for  a  dedicated  aerospace  or 
military  application)  without  incurring  the 
complete  cost  of  building  a  special-purposo 
high-assurance  TUB  from  scratch. 

In  addition  to  the  five  rings  dedicated  to 
the  evaluated  TCB,  three  additional  rings 
(for  a  total  of  eight)  are  made  available 
to  the  applications.  Nominally,  Ring  5  is 
allocated  to  operating  system  or  major 
system  applications  (such  as  DBMS  run-time 
modules),  Ring  6  to  "approved"  applications 
(i.e.,  those  that  have  passed  site-specific 
criteria  for  correctness  of  behavior),  and 
Ring  7  to  "ad  hoc"  applications  (i.e., 
those  that  are  under  construction,  or  whose 
trustworthiness  is  unknown).  It  would  be 
possible,  in  many  cases,  to  enforce  site- 
dependent  security  oontrols  (time  of  day, 
separation  of  duty,  etc. )  in  Ring  5  as  a 
refinement  to  conventional  discretionary 
and  mandatory  controls  without  disturbing 
the  evaluated  TCB  in  any  way  whatsoever. 

The  GEMSOS  Security  Kernel  uses  the  four 
hardware  privilege  levels  of  the 
0O286/SO3G6  to  enforce  the  ring  constraints 
on  a  process -by-process  bases.  Each 
process  may  have  only  throe  of  the  eight 
available  rings  active  at  any  given  time: 
a  typical  "application  process"  will  have 
available  two  rings  for  the  application 
code  with  the  most  privileged  of  the  three 
rings  dedicated  to  the  TCB.  Thus,  within 
the  address  space  of  each  process  one  finds 
code  for  accessing  services  through  the 
TCB,  code  for  operating  system  services, 
and  the  application  code.  Service  requests 
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are  typically  handled  without  the  need  for 
expensive  inter-prooess  communication  or 
context-switching  between  processes. 
Transfers  to  and  from  secondary  storage  are 
handled  (transparently  to  application 
programmers)  in  the  course  of  making 
segments  accessible. 

Multilevel  server  processes  (such  as 
terminal  servers  and  multilevel  channel 
servers )  have  two  aetivo  TCB  rings  and  one 
active  ring  available  to  non-TCB  functions. 
The  active  single-level  non-TCB  ring  in 
multilevel  server  processes  will  typically 
contain  non-security  relevant  operating 
systom  device  driver  functions  that  can  be 
customized  without  effecting  the  TCB. 
Application  processes  communicate  with 
multilevel  servers  via  inter-prooess 
communication.  Single  level  devices  can  be 
directly  attached  by  application  processes. 

Distributed  TCB  Interface 

Programs  external  to  the  TCB  gain  TCB 
services  via  a  program  interface  with  the 
ring  containing  the  discretionary  access 
control  mechanisms.  This  ring  is  referred 
to  as  the  "distributed  TCB"  in  that  it  is 
distributed  (in  the  address  space)  of  each 
of  the  system's  processes.  The  TCB 
supports  a  high  degree  of  concurrency  so 
that  more  than  one  application  process  can 
bo  "in"  the  TCB  at  the  same  time  where 
multiple  processors  are  available. 

Inter-Enclosure  Data  Communications 

The  GEMSOS  non-kernel  TCB  supports 
communication  between  enclosures  using 
multilevel  communication  channels.  These 
multilevel  channels  are  used  for  both  TCB 
and  non-TCB  communication  between 
enclosures. 

The  CEM30S  TCB  provides  applications  with 
an  interlace  that  allows  an  application 
process  in  one  enclosure  to  send  arid, 
receive  information  to  other  application 
processes  executing  in  another  enclosure. 
The  TCB  also  supports  the  remote  creation 
of  application  processes  with  the  same 
security  attributes  as  the  creating 
process:  thus,  it  is  straightforward  (from 
the  application  programmer's  point  of  view) 
to  provide  a  remote  processing  capability, 
while  the  security  enforcement  of  the 
distributed  system  is  not  compromised.  If, 
for  instance,  audit  logging  is  centralized, 
the  creation  of  a  remote  process  and  its 
subsequent  activity  will  be  correctly 
logged  by  the  TCB  and  associated  with  the 
user  identified  with  the  original  process 
by  the  TCB  without  the  application  designer 
having  to  make  any  special  provisions  for 
this  to  happen. 

Tne  abstract  inter-enclosure  communications 
capability  provided  to  applications 
programmers  may  be  described  as  an 
enclosure-to-enciosure,  connection- 
oriented,  transaction  based  communications 
system  appropriate  for  use  in  a  distributed 


architecture.  The  evaluatable  design  does 
not  specifically  address  the  needs  of  more 
dynamic  networks  of  enclosures  linked  by 
unreliable,  or  physically  insecure, 
communications  channels,  though  the 
underlying  design  is  extensible  to  support 
such  systems. 

The  non-kernel  TCB  uses  the  inter- enclosure 
communications  functions  for  TCB 
communications  among  enclosures  within  a 
system.  In  distributed  systems  (viz.,  those 
containing  more  than  one  enclosure), 
certain  TCB  databases  can  be  centralized  in 
an  enclosure  that  provides  TCB  services  to 
the  remaining  system  enclosures.  Audit 
records  are  collected  at  a  central  point, 
and  the  difficult  problems  associated  with 
concurrent  user  permission  databases  are 
avoided. 

Distributed  systems  containing  multiple 
loosely-connected  enclosures  inter¬ 
connected  by  multilevel  channels  can  be 
viewed  as  a  single  trusted  system  having  a 
single  TCB.  Thus,  a  distributed  Gemini 
system  possesses  a  coherent  Network 
Security  Architecture  and  Design,  as 
defined  in  the  Trusted  Network 
Interpretation  [8],  The  anticipated  formal 
evaluation  for  compliance  with  the  Class  A1 
of  the  TC'SEC  [3]  will  be  for  a  generalized 
multi-enclosure,  distributed  architecture 
so  that  the  evaluation  results  will  be 
immediately  applicable  for  applications 
making  no  modifications  to  the  TCB,  but 
requiring  a  distributed  architecture  (o.g,, 
if  MLS  AT  workstations  are  used). 

EXISTING  AND  PLANNED  APPLICATIONS 

Unisys  Defense  Systems 

In  his  oral  presentation  at  the  1988  IEEE 
Symposium  on  Security  and  Privacy  [9], 

Clark  Weissman  of  Unisys  stated  that  the 
GEMSOS  security  kernel  was  usee1  by  Unisys 
Defense  Systems  in  their  design  and 
implementation  of  e  federal  communications 
system  called  Blacker,  meeting  the 
requirements  for  Class  Al. 

In  his  presentation  at  the  10fi  National 
Computer  Security  Conference,  Jon  Fellows 
of  Unisys  stated  that  the  GEMSOS  kernel, 
along  with  other  trusted  components,  is 
used  as  the  basis  for  trust  for  critical 
cryptographic  and  key  distribution 
functions  that  maintain  communications 
separation  by  cryptographic  means.  [10) 

SACLANT 

Multiprocessor  Gemini  systems  and  50  MLS  AT 
Workstations  configured  in  a  "star-"  network 
were  included  in  the  accepted  CDR  presented 
by  Contel  Federal  Systems  as  part  of 
Contel's  contract  to  develop  the  SACLANT 
Command  and  Control  Information  System  for 
NATO.  The  design  includes  the  GEMSOS 
security  kernel  and  a  subset  of  the  GEMSOS 
non-kernel  TCB  elements  [11] . 
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IB ERL ANT 

A  configuration  of  Gemini  computer  systems 
similar  to  that  used  in  the  SACLANT 
architecture  was  part  of  Contel  Federal 
Systems'  winning  proposal  to  develop  the 
IBERLANT  Command  and  Control  Information 
System  for  NATO. 

Message  Editing  and  Preparation 
Demonstration 

Astronautics  Corporation  of  America  (ACA) 
has  developed  a  multilevel  secure  message 
editing  and  preparation  demonstration  on 
the  MLS-AT  Workstation  configuration  of  the 
GEMSOS  security  kernel  and  a  subset  of  the 
GEMSOS  non-kernel  TCB.  This  demonstration 
includes  message  creation  with  message 
masks,  message  editing,  transmission  and 
reception  of  messages  over  multilevel 
communication  channels  and  message 
printing. [12] 

Grumman  Data  Systems 

At  the  1988  AFCEA  international  Conference 
and  Exposition,  Grumman  Data  Systems 
developed  and  demonstrated  a  front  end 
secure  communications  processor  that 
provides  users  at  terminals  acoess  to 
information  at  multiple  levels  while 
maintaining  a  single  system  view  for  the 
user.  The  secure  communications  processor 
allows  users  to  connect  to  one  of  multiple 
back  end  host  computers  that  run  at 
different  security  levels.  Users  may  also 
establish  multiple  sessions  with  hosts  at 
different  acoess  classes  through  the  use  of 
multiple  "logical  terminals". 

The  demonstration  included  security 
administrator  support,  system  manager 
support  and  auditing. 

Martin  Marietta  Information  and 
Communications  Systems 

Martin  Marietta  has  been  using  Gemini  TCB 
products  for  over  three  years  for  their 
internal  multilevel  security  development 
effort,  and  has  developed  the  following 
demonstrations  and  capabilities: 

Trusted  Network  Access  Processor  with 
Trusted  Ethernet  Interface 

Trusted  Terminal  Gateway 

Trusted  File  Transfer 

The  following  projects  are  in  development 
at  this  time: 

Trusted  End-to-End  Protocol 
Trusted  Guards 


CURRENT  RESEARCH 

In  addition  to  supporting  applications- 
oriented  projects  such  as  those  described 
above,  Gemini  is  involved  in  several 
projects  oriented  towards  increasing  the 
number  and  range  of  environments  supported 
by  the  same  underlying  eeourity  kernel. 

The  projeots  described  below  differ  from 
routine  product  malntenanoe  and  enhancement 
because  they  are  oriented  toward  expanding 
the  base  of  customers  interested  in  using 
trusted  systems,  primarily  by  providing 
standard  system  interfaces  emulated  using 
an  unmodified  underlying  security  kernel. 

Oracle 

Oracle,  incorporated,  has  undertaken  an 
internal  research  and  development  effort  to 
upgrade  their  relational  DBMS  product  to 
Class  C2  end  to  investigate  a  further 
upgrade  to  the  B  division.  As  part  of  this 
effort,  it  is  expected  that  a  prototype 
version  of  the  C2  Oraole  DBMS  will  bo 
ported  to  the  GEMSOS  TCB.  Later,  a 
follow-on  port  of  the  B  division  prototype 
will  be  ported  to  the  GEMSOS  TCB.  Oracle 
engineers  have  also  been  reviewing  the 
design  documentation  prepared  for  the 
SeaView  Secure  Data  Views  project,  an  Air 
Force-sponsored  effort  awarded  to  SRI 
International  and  Gemini  to  design  a  Class 
A.l  multi-level  secure  DBMS.  The  near-term 
design  produced  under  thiB  project  features 
the  utilization  of  an  architecture  aimilar 
to  that  which  is  expected  to  result  from 
the  Oracle  port  to  provide  enhanced 
security  functionality. 

If  completed,  this  architectural  approach 
will  provide  multilevel  relational  DBMS 
functionality  to  customers  requiring  a 
Class  A1  level  of  assurance  in  the  form  of 
a  conventional  Oraole  DBMS  executing  as  a 
secure  application  on  the  GEMSOS  TCB. 

UNIX 

Gemini  is  currently  developing  a  UNIX 
emulation  that  will  present  the  Unix  kernel 
interface  to  application  programs.  The 
GEMSOS  TCB  has  been  designed  from  the  onset 
to  include  -chose  specific  features  needed 
to  support  an  efficient  UNIX  kernel 
implementation.  The  UNIX  kernel  functions 
will  execute  in  a  ring  less-privileged  than 
the  underlying  TCB  but  tamparproof  with 
respect  to  UNIX  application  programs. 
Becausa  the  UNIX  kernel  functions  are  less 
privileged  than  the  TCB,  they  do  not 
compromise  the  evaluation  of  the  underlying 
TCB.  Because  they  are  more  privileged  than 
applications,  the  integrity  of  the  UNIX 
kernel  cannot  be  compromised  by  application 
programs,  just  as  one  would  expeot  for  a 
conventional  UNIX-based  system. 


integration  of  Gemini  Trusted  Products  It  might  be  not«d  that  at  Class  B3  and 

with  a  Secure  Local  Area  Network  above,  the  TCSEC  requirement  to  make  the 

TCB  "minimal"  preoludes  the  competing 
architectural  approach  of  lower  classes  of 
making  the  Unix  kernel  and  TCB  interfaces 
the  same  interfaoe:  many  Unix  kernel 
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functions  are  not  security  critical  and 
must  be  implemented  outside  of  a  Class  B3 
or  A1  TCB . 

MS-DOS 

Gemini  is  currently  developing  an  80386- 
based  virtual  machine  monitor  and  BIOS 
emulation  that  will  allow  selected  standard 
MS-DOS  applications  to  execute  in  the 
environment  of  a  dedicated  MS-DOS  virtual 
machine.  While  this  approach  has  some 
intrinsic  limitations  (MS-DOS  applications 
that  bypass  BIOS  will  not  execute 
correctly)  the  availability  of  executable 
applications  is  believed  to  be  sufficiently 
broad,  and  to  encompass  a  sufficiently  wide 
range  of  functionality,  that  this  is 
believed  to  represent  a  cost-effective 
approach  to  obtaining  access  to  a  broad 
commercial  software  base  for  Claes  A1  or  B3 
systems.  The  intended  application  of  thiB 
capability  would  be  to  (in  effect)  make  a 
DOS  PC/AT  workstation,  supporting  a  set  of 
selected  DOS  applications,  available  to  the 
user  of  an  MLS  AT  workstations,  at  whatever 
authorized  session  level  the  user 
negotiated.  A  change  in  session  level 
would  appear,  in  most  respects,  to  the  user 
as  if  a  new  dedicated  PC/AT  workstation  was 
now  in  use.  Volumes  at  the  same  or  lower 
accesB  classes  can  be  shared. 

SUMMARY 

The  Gemini  product  line  is  based  upon  the 
use  of  a  single,  high-performance, 
general-purpose  security  kernel  designed  to 
be  evaluatable  at  Class  A1 .  The  security 
kernel  haa  been  commercially  available  for 
several  years  and  is  currently  being  used 
for  a  number  of  important  government 
communication,  command,  control,  and 
intelligence  applications.  It  has  also 
been  found  useful  by  a  number  of  vendors  in 
support  of  their  internal  programs  to  stay 
in  the  forefront  of  trusted  systems 
technology.  The  usability  of  the  security 
kernel  for  such  purposes  well  in  advance  of 
the  availability  of  an  evaluated,  complete 
Gemini  TCB  is  a  direct  design  consequence 
of  the  underlying  product  deoision,  made 
well  before  the  kernel  was  started,  to 
pursue  a  market  strategy  based  upon  an  open 
and  extensible  architecture,  serving  a 
growing  community  of  third-party  and 
value-added  customers.  ThiB  decision  led 
in  turn  to  a  design  based  upon  a  TCB 
composed  of  subsets  with  lndependently- 
evaluatable  layers,  the  most-privileged  of 
which  is  the  security  kernel  itself. 

In  addition  to  allowing  the  security  kernel 
to  be  independently  implemented,  tested, 
and  marketed  before  completion  of  the 
remainder  of  the  TCB,  such  a  subsetted 
design  allows  customers  to  use  unchanged, 
modify,  or  replace  the  remainder  of  the  TCB 
as  warranted  by  their  needs,  with  a  minimum 
impact  on  the  magnitude  of  the  re- 
evaluation  task.  We  expect  this  subsetted 
architecture,  along  with  the 
co8t/per£ormanoe  advantage  intrinsic  to  a 
multiple  microprocessor  capability,  to  be 


our  major  advantages  as  competing  Class  A1 
and  R3  systems  emerge. 

We  hope  to  conaretely  demonstrate  the 
additional  potential  of  an  extensible 
security  architecture  through  some  of  the 
research  efforts  described  above. 

Our  product  plan  includes  a  UNIX  emulation 
implemented  on  top  of  the  commercial  TCB. 

At  the  current  time,  we  also  expect  to  port 
the  Oracle  DBMS  directly  to  the  TCB 
interface  (not  the  Unix  emulation 
interface),  primarily  so  that  the  good 
performance  oharaoteristioe  of  the  TCB  are 
made  available  to  the  Oracle  DBMS. 
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Abstract 

A  major  challenge  t'acing  the  Strategic  Defense 
Initiative  (SDI)  program  and  the  development  of  the 
Strategic  Defense  System  (SDS)  is  the  use  and 
distribution  of  reusable  software,  The  need  for 
reusable  software  has  clearly  been  established  by  the 
ever  increasing  cost  of  software  versus  the  cost  of 
hardware.  This  cost  disproportion  is  magnified  in  a 
program  with  the  scope  of  the  SDS,  A  SDS  Software 
Library  will  be  created  in  which  reusable  software  can 
be  cataloged,  accessed,  and  distributed,  A  key 
attribute  of  this  library  is  security.  The  software 
in  the  SDS  Software  Library  must  be  protected  from 
unauthorized  access  and  modification.  This  paper 
demonstrates  the  need  for  a  secure  SDS  Software 
Library  and  the  means  by  which  this  can  be  achieved. 

Introduction 

The  Strategic  Defense  Initiative  (SDI)  program  is 
an  impetus  to  technology  developments  on  u  wide 
variety  of  fronts.  Two  of  these  fronts  are  computer 
hardware  and  software  development,  The  SDI  program  is 
computationally  intensive,  requiring  tomorrow's 
supercomputers  today.  This  technological  pace  must  be 
matched  by  equally  intensive  software  development. 

The  trend  over  the  past  decades  has  shown  us  that 
software  technology  always  lngs  hehind  hardware 
technology.  Total  software  costs  are  rapidly  growing 
as  machines  become  less  expensive,  and  as  we  uncover 
more  und  more  problem  domains  that  demand  an  automated 
solution  [1],  Second  and  third  generation  software  is 
hosted  on  fourth  generation  machines.  Furthermore, 
when  new  hardware  demands  new  software  solutions,  old 
software  is  frequently  "patched  up."  More  often  than 
not,  systems  fail  in  their  promise  to  be  extensible 
and  maintainable.  In  response  to  this  software 
crisis,  the  Department  of  Defense  sponsored  the 
development  of  the  Adu  utogiamming  language  wut  wtth 
it,  the  true  potential  of  reusable  software, 

The  SDI  program  will  make  great  use  of  reusable 
software,  There  is  neither  the  time  nor  the  money  to 
develop  a  software  system  "from  scratch"  for  each  new 
project.  In  addition  to  developing  new,  reusable 
softviare,  the  SDI  program  will  make  great  use  of 
legacy  software,  especially  in  the  initial  phaaes  of 
the  program.  The  use  of  Ada  is  only  a  partial 
solution  to  the  problem  of  software  reuse,  No  amount 
of  software,  whether  written  in  Ada  or  FORTRAN,  will 
encourage  reuse  if  it  is  not  accessible.  For  code 
reuse  to  be  attractive,  the  overall  effort  to  reuse 
code  must  be  less  than  the  effort  to  create  new  code 
[2],  Reusable  software  must  be  organized  in  a  central 
repository  to  which  authorized  software  developers 
have  ready  access,  It  must  be  organized  in  such  a 
manner  as  to  provide  rapid  response  to  requests  for 
reusable  modules  to  meet  tho  requirements  of  software 
developers,  Otherwise,  software  developars  will 
design  expensive,  single  application  systems  rather 
than  waste  time  and  manpower  scouring  the  countryside 
for  a  modulo  that,  may  or  may  not  do  the  Job,  This 
requirement  for  a  repository  where  reusable  software 
modules  are  accessible  to  the  SDI  software  development 
community  has  resulted  in  the  Strategic  Defense 
Initiative  Organization  (S0I0)  mandating  the 
establishment  of  a  SDS  Software  Library  at  the 
National  Test  Facility.  [3] 
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The  purpose  of  this  paper  is  to  focus  on  the  need 
and  method  of  achieving  a  secure  SDS  Software 
Library.  This  will  be  addressed  in  the  remaining  four 
sections,  each  presenting  the  security  issues  in 
succeeaingly  finer  levels  of  granularity.  First,  the 
requirements  for  a  secure  library  is  Examined. 

Second,  a  conceptual  model  outlining  the  required 
operational  capabilities  is  presented.  Third,  an 
implementation  is  suggested,  Finally,  the  previous 
material  is  summarized. 

Security 

Tho  success  of  the  SDS  Software  Library  can  only 
be  assured  by  the  proper  application  of  proven 
security  measures,  A  failure  to  do  this  will  result 
in  a  library  where  hostile  agents  can  siphon  national 
secrets  without  detection.  The  library  will  contain  a 
concentrated  data  base  of  software  revealing  a  great 
deal  of  the  capabilities,  und  vulnerabilities  of  the 
Strategic  Defense  System.  This  concentration  of 
defense  software  in  one  location  makes  the  SDS 
Software  Library  a  high  visibility  target,  The  data 
tables  that  are  included  in  many  classified  simulation 
software  packages  are  a  high  motivator  for  illegal 
penetration  into  the  library.  Unauthorized  access  to 
the  SDS  Software  Librury  can  result  in  tho  compromise 
of  information  or  corruption  of  software,  thereby 
resulting  in  a  severe  impact  to  national  security, 

In  a  recent  tutorial  (4],  a  majority  of  papers 
addressed  the  design  and  structure  of  software  for 
reusability.  A  lesser  number  were  concerned  with  the 
actual  implementation  of  u  software  library.  Not  a 
single  paper  addressed  security. 

One  reason  that  security  is  not  a  principal 
concern  of  software  library  developers  Is  that  the 
principal  beneficiaries  of  reusable  software  ore  the 
software  developers  themselves.  The  savings  may  be 
passed  on  to  the  buyer  (i.e.,  the  government),  but  the 
actual  software  development  and  savings  through 
reusability  are  an  "in  house"  issue. 

If  the  particular  softwure  project  is  classified, 
the  development  is  usually  accomplished  at  the  system 
high  level  where  all  users  are  cleared  to  the  highest 
level  of  the  eata,  The  programmers  and  the 
development  system  are  collocated  adding  to  the  amount 
cf  security  which  can  be  enforced  through  physical 
means.  The  situation  in  the  SDS  Software  Library  1b 
quite  different  due  to  its  handling  of  material  of 
various  classification  levels  Bnd  its  distributed  user 
base,  therefore  making  a  system  high  implementation 
inefficient . 

The  software  stored  in  the  library  and  the  users 
of  the  library  will  span  a  wide  rsnge  of 
classification  levels.  The  flexibility  necessary  for 
the  library  to  be  responsive  to  all  classification 
levels  eliminates  the  option  of  system  high 
operation.  Since  the  SDS  Software  Library  does  not 
actually  execute  programs,  the  security  treatment  is 
different  from  that  of  other  computer  systems.  The 
true  problem  is  how  to  enforce  security  when  such  a 
large  number  of  users  have  access  to  such  a  wide  range 
of  storage, 
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Conceptual  Model 

The  SDS  Software  Library  is  a  storage  facility 
for  reusable  software  serving  a  widely  distributed 
network  of  users,  The  library  enables  the  SDi 
software  development  community  to  efficiently  produce 
complex  software  systems  by  providing  access  to  an 
existing  software  base.  The  library  Is  the  central 
point  of  access  to  these  reusable  software  modules,  A 
conceptual  model  of  the  library  is  an  enumeration  of 
the  services  and  functions  the  library  must  provide. 
The  services  and  functions  exist  independently  of  the 
library's  actual  physical  configuration.  It  is, 
however,  difficult  to  create  an  abstract  functional 
concept  without  first  defining  the  physical  components 
that  constitute  a  software  library.  The  following 
will  briefly  describe  the  physical  elements  of  the 
library. 

The  core  of  the  software  library  Is  the  computer 
system,  its  software,  and  the  associated  storage 
system.  The  computer  system  provides  on-line  library 
services  to  the  users  by  executing  an  application 
program  referred  to  in  this  paper  us  the  Software 
Library  Management  System  (S1.MS).  The  SLMS  is  the 
user  interface  to  the  Information  sLored  in  the 
library  and  Is  the  system  by  which  the  administrative 
personnel  operate  the  library,  The  5IHS  provides  such 
services  as  catalog  lag,  tracking,  version  control,  und 
integrity  vorlt lent  ion  of  sofiwuro  items. 

It  Ls  Important  to  note  that  iho  library  is  not 
exclusively  an  electronic  storage  facility.  As  In  a 
conventional  library,  informul ton  can  be  maintained  in 
the  form  of  printed  material  or  microfilm.  A  user 
could  request  Lite  mailing  or  Ln  the  case  of  extremely 
sensitive  Informul  Ion,  Lite  transfer  by  courier  of  the 
requested  mnt.eriuL.  This  nonelectronic  extension  of 
the  library  divides  the  storage  media  Into  twu 
groups!  on-line  and  off-line.  Material  In  on-line 
storage  is  accessible  to  the  users  through  the  SLMS. 
Material  in  off-line  storage  la  IransinLLted  through 
more  traditional  means. 

'I'lie  administrative  personnel  of  the  library  serve 
two  purposes.  'I lie  first  Is  In  the  computer  system 
operating  stuff.  The  second  function  Is  the  entry 
point  lor  sol Lwnre  submitted  to  the  library. 

So  far,  we  have  viewed  the  library  as  nil 
Information  source.  Prior  to  being  a  source,  the 
library  must  acquire  software  items.  This  acquisition 
phu.se  Is  a  continuing  process.  The  SI.MS  is  the  filter 
for  Informal  Ion  flowing  from  the  library  to  the 
users.  The  f Liter  lor  mutor.lul  being  submitted  to  the 
library  is  the  administrative  personnel.  The  reasons 
for  a  nonmitomated  mechanism  are  both  technical  and 
philosophical.  Current  technology  does  not  enable  the 
creation  of  a  system  which  cun  examine  u  piece  of 
code,  analyze  it,  assess  its  worth  in  terms  of 
usefulness  and  reusability,  and  Intelligently  catalog 
It.  The  second  reason  Involves  the  humun  element. 

The  degree  of  confidence  users  would  have  la  software 
obtained  from  the  library  is  dubious  if  there  Is  not 
some  Intuitive  assurance  that  a  human  has  at  least 
reviewed  the  software  for  content  nnd  potential. 

A  conceptual  model  of  the  library  is  derived  from 
u  derailed  look  al  the  services  and  functions  required 
of  the  library  to  operate  smoothly  and  efficiently. 
Tills  Is  formally  expressed  by  a  set  of  required 
operational  capabilities.  The  required  operational 
capabilities  ure  u  functional  decomposition  of  the  SDS 
Software  Library,  They  state  what  services  the 
library  provides  Lo  Its  users  and  specifies  the 
interaction  between  the  users  nnd  the  library.  The 
required  operational  capabilities  determine  the  system 


level  requirements  for  the  library.  They  arc  not  an 
all  Inclusive  listing  of  functions  and  services. 
However,  the  required  operational  capabilities  must  be 
comprehensive  so  that  additional  requirements  support 
the  composite  system  without  compromising  any 
Individual  operational  capability  or  degrading  one 
another.  The  following  is  n  listing  of  the  minimal 
required  operational  capabilities. 

Fundamental  Capabilities 

Most  computer  operating  systems  enforce  a 
relationship  between  the  users  and  objects  such  on 
files  nnd  programs.  These  relationships  are  usually 
expressed  as  rend,  write,  and  execute  capabilities. 

In  essence,  the  SDS  Software  Library  is  a  system  with 
u  large  number  of  users  und  objects.  As  a  top  level 
specification,  the  fundamental  access  capabilities 
apply  as  follows! 

Bend  i  The  library  users  und  administrative 
personnel  will  have  rend  access  capabilities  as 
specified  by  their  Individual  access  rights. 

Write!  Only  the  administrative  personnel  shall 
have  write  access  capabilities  as  specified  by  their 
individual  access  rights. 

Annelid!  This  is  a  limited  write  capability  tu 
allow  the  addition  of  information  to  an  existing 
package.  The  SLMS  will  account  for  updates. 

Kxccute i  The  SDS  Software  Library  shall  not  have 
the  capability  Lo  execute  any  software  item  stored  In 
the  library.  The  SDS  Software  Library  is  a  software 
repository,  not  a  software  development  renter,  The 
only  software  the  library  will  execute  is  the  SLMS. 

Access  Modes 

The  users  of  the  SDS  Softwure  Library  shall  have  two 
modes  of  access  to  the  library!  sysLcm  nnd  retrieve. 

System!  In  tills  mode,  the  user  communicates  with 
the  SLMS.  A  typical  funcL Lon  in  the  system  node  la 
accessing  the  SDS  Software  Library  Cntulog.  This  mode 
may  however  have  access  limitations  (e.g,,  an 
unclassified  user  will  not  be  able  lu  scan  classified 
summaries  of  classified  items). 

Ret, r leve;  This  mode  grants  the  user  direct  read 
access  to  a  software  Item,  Notice  that  rend  access  is 
u  de facto  retrieve  mode  since  it  ts  impossible  to 
control  a  situation  where  u  user  at  n  remote  terminal 
chooses  to  downloud  the  Information  appearing  on  his 
terminal. 

Access  Paths 

The  SDS  Software  Library  shall  support  the 
following  means  through  which  users  may  access  the 
library: 

Local !  Authorized  users  ut  the  library  facility 
should  have  direct  access  to  the  library. 

Remote!  Authorized  users  will  be  able  to  access 
the  library  via  commercial  telecommunication  links. 

Dedicated:  The  SDS  Software  Library  shall 
support  dedicated  electronic  communications  links.  In 
the  case  of  classified  material,  these  links  will  be 
encrypted . 

Other !  Authorized  users  may  be  able  to 
communicate  with  the  library  via  telephone,  mail, 
courier,  and  other  nonelectronic  means. 
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Access  Controls 

In  accordance  with  the  Department  o f  Defense 
Trusted  Computer  System  Evaluation  Criteria  (TCSEC) 
[5],  the  library  shall  Incorporate  discretionary  and 
mandatory  access  conLrols  and  labels  for  an  A1 
system.  There  will  be  aome  differences  between  the 
TCSEC  and  the  implementation  In  the  library  due  to  the 
fact  that  the  library  users  have  no  write  capability 
and  that  the  library  is  not  capable  oT  executing 
stored  software  items. 

Arcountiib.il  1 1 V 

The  SDS  Software  Library  shall  incorporate 
mechanisms  to  enforce  Lite  Identification, 
authentication,  and  audit,  requirements  as  specified 
for  an  A1  uysLom  by  the  TCSEC, 

lit  tear  I  ty  Controls 

The  SDS  Software  Library  shall  maintain  software 
Inlegrlly.  Integrity  mechanisms  ensure  that  the  state 
nf  a  software  Item  Is  identical  (i.e.  has  not  been 
modified)  to  Its  suite  ill.  a  previous  time.  The  proper 
use  of  access  controls  and  integrity  locks  ensure  that 
soi  l  ware  is  null  nUrinetl  ami  updated  under  strict 
rout rol, 

To  ensure  that  data  integrity  is  maintained,  the 
ncress  to  l hut.  data  must  lie  controlled.  The  SDS 
Software  Library  access  controls  are  taken  from  tho 
TCSEC.  David  Clark  and  David  Wilson,  In  mi  IEEE 
paper,  "A  Comparison  of  Commercial  and  Military 
Computer  Scour ily  Policies,"  argue  thai  the  military 
Meciirtly  policy  only  protects  Information  from 
unauthorized  disclosure.  If,  however,  u  user  l.s 
authorized  to  access  u  purl  Icular  data  Item,  there  Is 
no  rest rli l  lun  on  how  that  data  can  he  manipulated 
|6|.  The  protect  Ion  from  unauthorized  modification 
can  be  Implemented  III  one  of  two  wuys.  The  first  Is 
to  pLuro  Integrity  protection  met  lain  Lams  between  the 
user  and  the  iiiforiiintlon.  This  protection  would  be  in 
nddlttmi  to  existing  access  controls,  Tho  second  Is 
lo  eliminate  the  user's  ability  to  modify 
Information,  The  latter  method  is  Inherent  In  the 
read  only  funct tonality  of  the  library. 

Integrity  locks  determine  If  Information  has  been 
modified.  An  Integrity  test  ran  be  performed  to 
verify  that,  the  present,  statu  ol  a  so  ft  wore  Item  is 
unchanged  from  some  previous  slate.  Additionally, 
al let  a  software  item  Is  distributed  to  one  or  more 
users,  the  sumo  capability  must  exist  at  the  remote 
location  to  verily  that  Ihe  state  of  that  Item  matches 
the  stale  of  Its  parent  in  the  library. 

The  SDS  Software  Library  will  be  required  to 
store  software  modules  having  different  levels  of 
clnsnl  I'  lent  Ion  (l.e.  multilevel  secure  storage). 

Also,  cerL.iln  Items  may  be  under  strict,  control 
independent  of  rlnssi f lcatJon  level.  Items  under  leas 
stringent  control  should  have  u  wide  availability 
while  those  under  strict  control  must  have  very 
limited  distribution. 

Since  the  SDS  Software  Library  la  n  software 
storage  facility,  not  a  software  development,  center, 
all  storage  will  appear  to  be  of  the 
wr  I  le-once-read-inuny  lype. 

Software  Entry 

Software  Items  are  entered  Into  the  SDS  Software 
Library  only  by  the  administrative  personnel.  The 


submitter  of  the  software  item  must  provide  the 
following: 

Header t  The  header  contains  the  authors, 
organization  date,  language,  system,  and  system 
configuration  on  which  and  for  which  the  software  item 
was  developed. 

Pedigree:  A  clear  and  detailed  development 
history  of  the  module.  This  will  specify  the  current 
version  number  as  well  11s  previous  versions, 
independent  of  wheLher  or  not  those  previous  version 
exist  in  the  library.  The  pedLgree  shall  also  stnto 
the  program  for  which  the  item  was  developed  and  the 
tost  and  verification/validation  history. 

Functional  Specification!  A  textual  document 
detailing  the  precise  function  of  the  softwure  item. 

Interface  Control  Document  (ICD);  A  formal 
document  indicating  all  entry  and  exit:  points,  data 
structures,  data  types  and  any  other  operational 
requirements  necessary  to  execute  the  software  item 
per  its  specifications. 

Current  technology  does  not.  permit  the  formnl. 
verification  of  software  at  the  code  level.  The 
ability  to  automatically  analyze  software  and 
determine  if  it  contains  trojan  horses,  viruses,  or 
other  malicious  functionality  is  still  years  away. 

This  leaves  no  other  alternative  hut  Lo  distrust  all 
software  entered  into  the  library.  The  s.ivLng  grace 
of  this  bleak  fact  Is  the  nonexecutable  nature  of  the 
library.  Programs  containing  a  virus  cannot  propagate 
to  other  programs  stored  In  the  library  since  they 
will  not  he  executed  in  the  library,  it  la  the  user 
who  assumes  responsibility  for  the  correct  or 
Incorrect  functioning  of  a  software  item  obtained  from 
the  library, 

Dlstribut Ion 

Software  distribution  Is  tho  transmission  of  a 
software  .Horn  to  one  or  more  authorized  users  via  an 
approved  access  path.  The  library  shull  provide  for 
trusted  distribution  of  software, 

Catalog 

The  library  will  nuilnlnin  n  catalog  of  all 
software  Items  stored  In  the  library.  "The  library 
shall  contain  procedures  t.linl  help  construct  queries 
and  evaluate  tile  retrieved  sample  for  potential 
reusability."  [2] 

Physical  Security 

The  .SDS  Software  Library  central  host  computer 
system  must  be  sltuuLod  In  a  physically  secure  area. 
Protection  must,  be  offered  to  prevent  unauthorized 
access  Lo  Information  and  to  prevent  the  malicious 
destruction  of  hardware,  software,  or  other  library 
elements  In  an  attempt  Lo  deny  service, 

Implenientat  ton 

In  order  for  the  SDS  Software  Library  to 
simultaneously  process  information  of  different 
sensitivity  levels  the  Department  of  Defense  requires 
the  library  to  be  a  trusted  system.  The  TCSEC  defines 
a  trusted  system  an  "A  syotem  thaL  employs  sufficient 
hardware  und  software  integrity  measures  to  allow  Its 
use  for  processing  simultaneously  a  range  of  sensitive 
or  classified  information."  [5]  The  EDS  Softwure 
Library  must  be  designed  as  a  secure  system  while 
preserving  the  required  functionality.  What  will  he 
presented  here  is  an  informal  implementation  outline. 
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This  implementation  fulfills  the  operational 
requirements  through  the  proper  application  of 
information  security  mechanisms.  It  will  examine  only 
the  electronic  portion  of  the  library.  The 
nonelectronic  areas  are  addressed  by  existing  policies 
for  the  handling  of  classified  material. 

At  the  center  of  the  library  is  the  computer 
system  which  controls  till  of  the  information  between 
the  users  and  the  storage.  No  user  has  direct  access 
to  the  library  storage  facility.  All  access  is 
mediated  by  the  central  computer  system.  In  addition 
to  enforcing  access  controls,  it  incorporates  other 
security  relevant  functions  such  ns  audit  trolls  and 
user  authentication.  As  stated  previously,  the  fact 
that  the  library  users  and  the  information  stored  in 
the  library  span  nil  clussif lent  Ion  levels  mandates 
the  ceuLral  computer  to  be  u  trusted  system, 

Tiie  requirements  for  the  type  of  trusted  system 
are  derived  from  the  publication  Guidance  for  Applying 
the  TCSKC  in  Specific  Environments  [7],  This  standard 
provides  guidance  to  determine  Lite  minimum  evaluation 
class  required  for  a  system  in  specific 
Implementation,  The  evaluation  class  determination  is 
based  on  three  factors!  the  minimum  use  clearance, 
the  maximum  data  sensitivity,  and  the  type  of  system 
(L.e,,  open  or  closed).  In  Lhe  case  of  the  SDS 
Software  Library,  the  minimum  user  clearance  Is 
unclassified.  We  will  assume  Lhe  maximum  dutu 
sensitivity  to  be  top  secret,  Thu  type  of  system  to 
ho  used  in  the  library  will  be  considered  a  closed 
system,  This  means  Lite  library  will  not  execute 
npplicnt tons  software  from  outside  sources.  The  only 
application  software  which  the  library  will  actually 
execute  is  the  SHIS.  This  will  be  developed  by 
cleared  personnel  under  n  Light,  ronflgiirul  lou 
controlled  environment.  Applying  the  guidance 
simulat'd  to  those  factors  results  Ln  a  criteria  class 
requirement  of  an  A1  system. 

The  SHIS  Is  the  npplicnt  Lon  package  hosted  on  the 
trusted  system.  The  SI.MS  Is  the  Interlace  through 
which  the  users  anil  admin  I  strut  l.ve  personnel  access 
ami  manage  the  library,  I  la  functions  include  those 
library  procedures  not  Inherent  In  the  operating 
system  of  the  trusted  computing  Imso,  These 
procedures  include  the  cut. a  log  lug,  trucking,  and 
overall  control  of  the  softwure  items  stored  in  the 
library.  The  security  feature  of  the  SHIS  is  the 
Integrity  locking  of  all  Informal  Ion  In  I  lie  library. 
There  Is  currently  no  standard  algorithm  or  device 
available  to  perforin  an  integrity  lock.  When  an 
algorithm  or  device  becomes  available,  It  would  he 
Integrated  Into  the  software  library  by  either 
software  or  hardware. 

An  A1  system  affords  the  data  separation 
necessary  to  allow  an  algorithm  to  be  Implemented 
directly  within  the  SIJ’IS,  This  procedure  could  append 
a  cryptographic  authentication  code  to  all  software 
items  entered  Into  the  library.  The  alternative  ts  a 
hardware  sealing  system  In  line  between  the  computing 
system  and  the  library  storage  facility.  Any 
nnnseuled  item  passing  from  the  system  to  the  storage 
la  appended  with  an  auLhent leal  Ion  code.  When  tin  Item 
is  transferred  from  the  storage  facility  It  must  pass 
through  lhe  hardware  system  where  an  Integrity  test  ts 
performed.  Any  Item  fulling  the  Integrity  test  would 
lie  I  lagged  and  rendered  unavailable  until,  sume 
corrective  action  Is  taken. 


The  final  level  of  security  to  consider  is  the 
communication  channels  linking  the  user  to  the 
library.  These  links  must  be  secure  In  order  to 
transfer  classified  information.  This  requires  the 
use  of  secure  gateways  to  the  library.  One 
possibility  is  to  locate  the  library  within  an 
existing  classified  data  communications  system. 
Sections  of  the  National  Test  Facility  provide  this 
capability.  Locating  the  SDS  Software  Library  within 
the  National  Test  Fncility  will  provide  the  SDS 
Software  Library  with  secure  duta  communication. 

Conclusion 

In  this  brief  treatment  of  a  complex  subject,  we 
have  stated  the  necessity  for  an  SDS  Software  Library, 
cited  its  required  operational  capabilities,  and  shown 
the  mandatory  role  that  security  must  play  to  create  a 
successful  system.  A  software  llbrury  is  the  only 
method  by  which  the  SDI  program,  or  any  program  of 
such  mugnitude,  can  accomplish  its  challenging 
software  development  tasks.  The  notion  of  reusable 
software  demands  u  ccntrul  access  facility.  A 
software  library  must  provide  a  broad  range  of 
services  to  entice  software  developers  Lo  make  good 
use  of  reusable  code.  None  of  these  services  should 
be  degraded  unnecessarily  by  the  proper  incorporation 
of  security. 

The  SDS  Software  Library  must  be  u  secure, 
trusted  system  to  nllow  Lhe  library  to  handle 
softwure  of  various  sensitivity  levels.  This  places 
stringent  requirements  on  the  system  us  n  whole 
spanning  the  areas  of  A1  level  trusted  main  ('fumes  lo 
creuting  and  standardizing  sccuie  and  vei  l  l  iable 
Integrity  locking  mechanisms.  Then'  are  many 
challenges  to  be  met  in  achieving  u  secure  SDS 
Software  Library.  Kit  I  lure  to  commit  to  the  security 
of  the  SDS  Software  Library  will  result  In  unusable, 
or  oven  malicious,  rather  than  reusable  soft ware, 
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Abstract 

The  multilevel  secure  automated  exchange  of 
military  messages  has  been  the  subject  of  much 
research  over  the  past  fifteen  years.  During  the 
last  decade,  several  attempts  to  Implement  military 
message  systems  with  Bell  and  LaPadula  security 
models  have  been  characterized  by  security  kernels 
with  poor  performance  and  a  resulting  security  model 
which  does  not  accurately  describe  the  real 
behaviour  of  a  military  message  system. 
Consequently,  the  Naval  Research  Lab  (NRL)  has 
developed,  and  is  promoting,  an  alternative  approach 
that  includes  an  application  based  security  model 
for  military  message  systems  [1].  These  facts  have 
prompted  Hagnavox  to  pursue  the  development  of 
verifiable  security  kernel  alternatives  capable  of 
enforcing  application  based  security  models. 

Our  resulting  product  is  the  Trusted  Military 
Message  Processor  ( TRUMMP )  and  the  Military  Message 
Embedded  Executive  [(ME2)].  The  TRUMMP  is  the 
hardware  base  that  provides  the  performance  and 
isolation  characteristics  necessary  for  the  (ME2), 
The  (ME2)  is  a  security  kernel  alternative  that  has 
as  goals:  enforcement  of  “ configurable "  application 
based  security  models,  and  real-time  performance. 
At  the  heart  of  the  (HE2)'s  ability  to  provide 
enforcement'  of  a  "configurable"  application  based 
security  model  is  a  state  machine  architecture  that 
provides  for  rigid  domain  separation  and  strongly 
typed  data  flows  over  secure  connections. 


INTRODUCTION 

The  Military  Message  Experiment  (MME)  was  a 
joint  research  effort  sponsored  by  the  Navy,  Defense 
Advanced  Research  Projects  Agency  (ARPA)  and  the 
Commander-in-Chief  Pacific  (CINCPAC)  to  produce  and 
evaluate  the  feasibility  of  developing  multilevel 
secure  military  message  systems,  That  project 
produced  SIGMA,  an  operational  system  that  was  used 
by  military  officers  and  staff  personnel.  Later 
evaluations  of  the  system  by  the  NRL  demonstrated 
the  serious  deficiencies  that  arise  when  a  military 
message  system  is  Implemented  with  a  Bell  and 
LaPadula  model.  For  background,  a  brief  summary  of 
the  NRL  findings  and  their  solutions  are  presented 
here.  Our  description  of  the  NRL  findings  are  taken 
from  [1], 

Reference  [1]  argues  that  a  security  model 
should  enable  users  to  understand  how  to  operate  the 
system  effectively,  implementors  to  understand  what 
security  controls  to  build,  and  certifiers  to 
determine  whether  controls  are  consistent  with 


directives  and  whether  controls  are  correctly 
implemented.  Reference  [1]  proceeds  to  describe 
three  deficiencies  of  the  Bell  and  LaPadula  model 
that,  prevented  the  model  from  providing  this 
guidance  to  SIGMA  users,  Implementors,  and 
certifiers.  Those  deficiencies,  as  described  in 
Ill ,  are  as  follows: 

Prohibition  of  write-downs.  The  *  (star) 
property  prohibits  tRTwriting''down  of  information 
to  a  lower  classification  level.  However,  under 
some  circumstances  this  action  would  be  secure  for  a 
military  message  system.  It  was  assumed  that  user 
confirmation  by  SIGMA  would  prevent  security 
violations  when  this  action  was  needed  but  because 
so  few  understood  the  security  policy  (a  phenomenon 
derived  from  the  numerous  exceptions  forced  by  the 
nature  of  the  application)  users  tended  to  always 
permit  these  actions  without  understanding  why  they 
had  been  questioned. 

Absence  of  multilevel  objects.  The  model 
recognizes  onTy  single-level  objects  when  in 
reality,  objects  for  a  military  message  system  are 
inherently  multilevel.  An  example  is  the  multiple 
paragraphs  of  a  message,  each  of  which  has  its  own 
classification.  By  treating  a  multilevel  object  as 
a  single  level  object,  some  information  is  treated 
as  more  classified  than  it  really  is. 

No  structure  for  application  dependent  security 
rules.  Tne modal  contains  no  structure  For 
application  dependent  rules.  A  military  message 
system  typically  must  enforce  some  security  rules 
that  are  unique  to  its  application.  An  example  is  a 
rule  that  allows  only  users  with  authority  to  invoke 
a  release  operation. 

Reference  [1]  continues  by  stressing  the 
deficiencies  of  approaches  that  attempt  to  fit  an 
application  on  top  of  the  general  purpose  Bell  and 
LaPadula  model.  The  need  for  application  based 
security  models,  as  opposed  to  Bell  and  LaPadula 
derivatives,  is  emphasized.  Such  a  policy  is 
defined  for  a  military  message  system. 
Implementations  are  purposely  omitted  so  that 
implementors  may  use  current  technologies  [1],  Our 
product  is  one  such  method  that  may  prove  useful  In 
the  implementation  of  application  based  security 
model s . 


Magnavox  is  coordinating  with  the  NSA/NCSC  as 
to  the  certification  of  TRUMMP  and  which  criteria  is 
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to  be  used.  The  evolution  of  our  product  suggests 
an  Interpretation  of  the  TCSEC  or  TNI  that  Is 
"unique"  to  the  processing  requirements  of  military 
message  systems  that  contain  multiple  embedded 
military  message  processors.  As  a  result,  our 
security  architecture  group  has  prepared  a  technical 
report  detailing  Issues  associated  with  an 
Interpretation  of  the  TCSEC  for  this  type  of  system 
[7].  In  any  event,  using  the  context  of  the  TNI.  as 
a  minimum,  our  goal  is  a  component  rating  .  M 
(Mandatory  Access  Control)  Implying  the  product  to 
be  applicable  to  the  81  through  A1  divisions  of  the 
TCSEC.  Verification  Issues  are  not  addressed  In 
this  paper  but  we  have  a  security  verification  and 
validation  group  that  Is  working  along  with  us  to 
assess  the  security  assurance  aspects  of  our 
development  [6]. 


This  paper  Is  organized  Into  six  major 
sections:  (1)  the  functional  and  security 
requirements  of  military  message  systems;  (2)  an 
overview  of  attempts  to  Implement  these  requirements 
with  security  kernels;  (3 )  definition  of  a  security 
kernel  alternative;  (4)  Implementation  of  this 
alternative  In  the  Military  Message  Embedded 
Executive  [ (ME2) ] ,  including  discussion  of  data  and 
process  security  enforcement;  (5)  a  description  of 
the  Trusted  Military  Message  Processor  (TRUMMP);  and 
(6)  our  conclusions  and  future  plans. 

1 .  FUNCTIONAL  AND  SECURITY  REQUIREMENTS 

Systems  that  are  used  to  process  military 
messages  are  concerned  with  the  handling  of 
different  message  types.  One  type,  the  formal 
military  message,  Is  at  the  heart,  of  Command, 
Control,  Communications  and  Intelligence  (C3I) 
systems.  Nearly  all  military  operations  and 
policies  are  communicated  through  a  formal  military 
message  [41.  Military  standards  which  govern  the 
format  of  these  messages  typically  require  a  TO, 
FROM,  INFO,  DATE-TIME-GROUP,  TEXT,  SECURITY,  and 
PRECEDENCE  field  for  each  message.  A  formal 
military  message  must  be  maintained  for  long  periods 
of  time  and  be  capable  of  being  quickly  retrieved. 

Another  type  of  military  message  Is  the 
Informal  message.  In  contrast  with  formal  messages, 
Informal  messages  generally  do  not  have  the  same 
storage  and  retrieval  requirements. 

The  systems  used  to  process  these  messages 
consist  of  both  embedded  processors  and  non-embedded 
processors.  An  embedded  processor  refers  to  those 
rocessors  that  do  not  contain  a  direct 
uman-machlne  Interface  (HMI)  but  are  still  a  vital 
processing  component  (e.g.  a  message  switch). 
While  most  non-embedded  processors  are  concerned 
with  the  unauthorized  disclosure  or  unauthorized 
modification  of  Information  to  users  (data 
security),  the  embedded  processor  must  also  enforce 
what  [3]  refers  to  as  process  security. 

For  an  embedded  military  message  processor,  a 
process  security  requirement  might  be  related  to  the 
precedence  of  tne  message.  In  a  military  message, 
the  precedence  specifies  the  maximum  delivery  time 
for  a  particular  type  of  message.  Consequently,  a 
process  security  requirement  for  a  military  massage 
system  might  state  that  higher  precedence  message 
processing  will  preempt  lower  precedence  message 
processing.  Enforcement  of  this  process  security 
requirement  by  the  embedded  computer  allows  the 
system  to  respond  to  high  priority  traffic  as 
quickly  as  possible.  In  a  C3I  environment 


enforcement  of  this  process  security  requirement  is 
as  important  as  the  security  requirements  related  to 
the  unauthorized  disclosure  and  unauthorized 
modification  of  data. 

Survivability  Is  another  fundamental  process 
security  requirement  for  a  military  message  system. 
Each  computer  resource,  embedded  or  non-embedded, 
must  continue  to  function/recover  in  the  presence  of 
simultaneous  jamming,  destruction,  and  nuclear 
blackout.  Ironically,  It  Is  in  the  face  of  these 
very  conditions  that  the  system  will  undoubtedly 
face  the  largest  volume  of  formal  message  traffic. 
Performance  under  these  stressful  conditions  becomes 
a  process  security  requirement  for  the  embedded 
computer  resources.  An  Important  derivative  of  this 
process  security  requirement  Is  denial  of  service 
protection.  Denial  of  service  protection  ensures 
that  no  one  process  monopolizes  resources  so  as  to 
delay  or  prevent  other  system  functions. 

Finally,  the  objects  of  a  military  message 
system  must  reflect  the  multilevel  nature  of  a 
military  message.  A  military  message  Is  often 
composed  of  paragraphs  of  differing  classification 
with  the  overall  classification  for  the  message 
equal  to  the  highest  classification  of  any  part  of 
the  message.  To  treat  the  entire  message  as 
classified  as  the  most  sensitive  portion  causes  some 
Information  to  be  treated  as  more  classified  than  It 
really  Is.  As  a  result,  an  Information  structure 
that  Is  capable  of  representing  the  multilevel 
nature  of  a  military  message  Is  required.  Reference 
[1]  refers  to  this  type  of  Information  structure  as 
a  "container". 

2.  EXPERIENCE  WITH  SECURITY  KERNELS 

Until  very  recently  the  security  kernel,  a 
reference  monitor  implementation,  has  been  promoted 
as  an  appropriate  foundation  for  meeting  nearly  all 
security  requirements.  By  enforcing  a  multilevel 
security  policy,  the  security  kernel  creates  an 
abstract  machine  upon  which  It  Is  impossible  for  an 
application  program  to  commit  compromise.  By 
restricting  the  role  of  security  enforcement  to  a 
small  and  simple  mechanism  such  as  a  security 
kernel,  security  verification  Is  much  more  tenable. 

In  a  military  message  environment,  however,  the 
first  attempts  to  Implement  military  message  systems 
were  faced  with  a  practical  problem  related  to  the 
nature  of  the  application.  Although  many  of  the 
required  actions  are  commonly  defined  as  secure, 
they  violate  the  general  purpose  axioms  of  the 
security  kernel  (1,e.  the  ‘-property).  An  example 
Is  the  classification  of  the  message  header 
Information  at  security  levels  lower  than  that  of 
the  associated  message  text.  To  solve  the  problem, 
these  systems  relied  on  numerous  trusted  subjects 
which  are  effectively  exceptions  to  the  general 
purpose  axioms. 

Security  kernel  performance  was  an  additional 
problem.  Some  kernels  yielded  performance  as  low  as 
10-25  percent  of  their  non-trusted  counterparts  [2]. 
With  good  performance  a  critical  requirement, 
security  kernels  did  not  yield  adequate  results. 
Yet  another  drawback  of  security  kernels  was  their 
absence  of  attention  to  the  process  security 
requirements  that  are  present  In  DoD  embedded 
computers. 

Thus,  some  alternatives  for  security 
enforcement  In  a  military  message  system  are:  1) 
develop  a  special  purpose  security  kernel  that  will 
enforce  a  model  tailored  to  military  message 
systems,  2)  use  a  Bell  and  LaPadul*  model  with 
numerous  trusted  subjects,  or  3)  use  a  security 
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kernel  alternative  [5j.  The  first  alternative  is 
extremely  costly,  and  the  second  alternative  yields 
a  product  with  the  problems  that  SIGMA  experienced, 
As  a  result,  TRUMMP  uses  a  security  kernel 
alternative,  (ME2),  pronounced  as  "ME  TWO",  to 
implement  application  security  models  specifically 
tailored  to  military  message  systems,  Fundamental 
to  our  approach  Is  the  concept  of  a  state  machine 
architecture. 

3.  A  SECURITY  KERNEL  ALTERNATIVE 

The  security  kernel  alternative  that  (ME2)  will 
use  to  enforce  an  application  security  model  Is 
based  on  the  concept  of  a  network  of  communicating 
finite  state  machines  (CFSM)  that  operate  under  the 
control  of  a  State  Machine  Executive  (SHE)  [5]  .  In 
our  development  the  (ME2)  Is  the  state  machine 
executive  that  provides  domain  concurrency,  domain 
separation,  Inter-domain  communication  via  message 
passing,  as  well  as  enforcement  of  application  based 
data  security  and  process  security  requirements. 
The  general  architecture  Is  referred  to  as  a  State 
Machine  Architecture  (SMA) . 


Sink  Station  -  The  tail  of  each  arrow  In  figure  1. 
Data  is  received  on  a  sink  station  from  a  source 
station,  A  connection  attached  to  a  sink  station  of 
a  node  Is  called  a  source  connection  for  that  node. 
Each  sink  station  represents  an  unbounded  FIFO 
queue,  the  tall  of  which  acts  as  the  sink  point  for 
source  connections,  while  the  head  acts  as  a  source 
station  for  sink  connections. 

Workstation  -  The  heads  of  the  queues  associated 
with  the  sink  stations  of  each  processing  node. 

Container  -  A  typed  Information  structure  that  is 
categorized  as  single-level  or  multilevel  based  on 
Its  typed  value.  For  example,  a  message  container 
is  a  multilevel  Information  structure  while  a 
control  container  is  a  single-level  Information 
structure. 

Data  Security  Labels  -  Container  labels  which 
Intricate  the  level  of  damage  that  might  result  if 
the  container  Information  is  subjected  to 
unauthorized  disclosure  or  unauthorized 
modification. 


3.1  Definitions 


The  following  definitions  are  provided  to 
establish  the  required  terminology  for  discussion  of 
the  Military  Message  Embedded  Executive  (ME2). 

Processing  Nodes  -  The  nodes  of  the  graph  In  figure 
1.  These  nodes  represent  a  processing  domain.  In 
the  context  of  a  military  message  system  a 
processing  node  might  represent  the  processing 
domain  responsible  for  displaying  a  message  while 
another  node  might  represent  the  processing 
associated  with  the  network  interface. 


Connections  -  The  arrows  of  the  graph  in  figure  1. 
These  arrows  represent  the  communication  channels 
between  processing  nodes.  Connections  may  be 
external  or  Internal.  An  Internal  connection  refers 
to  a  connection  that  nas  a  processing  node  for  both 
Us  source  and  sink  points.  Connections  that  do  not 
have  a  processing  node  for  sink  and  source  are 
external  connections. 

Source  Station  -  The  head  of  each  arrow  In  figure  1. 
Data  Is  sent'  from  a  source  station  to  a  sink 
station.  A  connection  attached  to  a  source  station 
of  a  node  is  called  a  sink  connection  for  that  node. 
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Process  Security  Labels  -  Process  labels  and 
container  label s  that  are  used  to  enforce  the 
process  security  requirements. 

In  the  State  Machine  Architecture,  the  heart  of 
security  is  the  domain  separation  mechanism  known  as 
the  State  Machine  Executive.  In  our  implementation 
the  State  Machine  Executive  Is  the  (ME2).  The  (ME2) 
is  the  foundation  that  supports  the  enforcement  of 
application  based  security  models.  In  addition  to 
supporting  application  based  security  models,  (ME2) 
allows  an  implementation  that  enjoys  performance 
advantages  over  traditional  security  kernel 
implementations. 


4,  Ihl  MILITARY  MESSAGE  EMBEDDED  EXECUTIVE 

The  Military  Message  Embedded  Executive 
[ (ME2)] ,  pronounced  as  "ME  TWO",  Is  an 
implementation  of  the  state  machine  executive 
described  In  the  previous  section.  This  section 
describes  the  (ME2)  Implementation  of  each  of  the 
state  machine  architecture  concepts  described  above. 

4.1  Processing  Nodes 

Processing  nodes,  also  called  logical 
processors,  are  the  components  of  the  state  machine 
architecture  that  refer  to  processing  segments  which 
operate  Independently  of  each  other.  In  a  military 
message  system,  one  processing  node  might  represent 
the  processing  associated  with  display  of  a  message 
while  another  node  might  represent  the  processing 
associated  with  a  network  Interface.  The 
fundamental  requirement  that  must  be  supported  In  an 
Implementation  of  a  processing  node  is  domain 
Isolation.  The  resources  of  each  processing  node 
must  be  Isolated.  In  a  single  computer 
implementation,  this  means  that  the  (ME2)  must 
Insure  that  the  computer  registers,  flags,  memory, 
and  code  of  one  node  are  physically  Inaccessible  to 
another  node.  Not  only  must  the  (ME2)  establish 
domain  Isolation  but  It  must  also  ensure  that  once 
established  that  the  processing  node  cannot  alter 
the  domain  Isolation  characteristics. 

Usually,  hardware  support  for  domain  Isolation 
and  domain  switching  has  been  rare.  Time  consuming 
operating  system  software  has  traditionally  been 
required  to  save  the  current  processor  domain  In 
memory  and  to  establish  or  load  a  new  domain.  The 


Figure  1.  A  State  Machine  Architecture 
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overhead  associated  with  this  single,  but  frequent, 
operation  has  been  cited  as  the  source  of  many 
performance  problems  in  previous  security  kernel 
implemen cations. 


Furthermore,  the  security  assurances  placed  in 
the  system  are  rooted  in  the  correctness  of  the 
software  used  to  implement  the  domain  Isolation 
principles.  The  more  complicated  this  software,  the 
less  likely  we  can  be  certain  that  the  software  Is 
implemented  correctly,  and  the  less  likely  that  the 
software  is  worthy  of  our  trust. 

To  combat  these  problems,  the  Intel  80286 
microprocessor  was  chosen  as  the  TRUMMP  CPU.  The 
Intel  80286  is  unique  for  its  ability  to  provide 
single  instruction,  firmware  based,  domain  switching 
in  as  little  as  16  microseconds,  With  the  Intel 
80286,  the  (ME2)  can  perform  an  entire  domain 
switching  operation  by  executing  a  single  privileged 
instruction  designed  to  change  the  current  task 
register  (see  figure  2). 

As  shown  in  figure  2,  the  Task  State  Segment 
(TSS)  is  a  hardware  recognizable,  and  hardware 
manipulated  structure  that  defines  the  contents  of 
all  machine  registers,  flags, code,  and  memory  that 
are  physically  visible  at  any  one  time.  In  the 
(ME2) ,  each  processing  node  has  an  associated  TSS 
that  completely  defines  th  node's  domain. 
Contained  in  the  TSS  is  the  address  of  another  Intel 
80286  data  structure  called  the  local  Descriptor 
Table  (LOT) .  The  LDT  is  the  TSS  component  that 
defines  the  memory  resources  and  code  segments  that 
are  associated  with  a  particular  processing  node. 
The  TSS  and  LOT  data  structures  are  made  invisible 
to  applications  in  two  ways.  First,  these  critical 
data  structures  are  contained  exclusively  within 
(ME2)  LOTs.  Second,  their  access  is  governed  by  a 
hardware  protection  mechanism  that  restricts  access 
to  "privilege  level  0"  code,  i.e.  (ME2)  code. 
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4.2  Connections 

Connections,  also  called  virtual  channels,  are 
the  communication  mechanisms  for  process  nodes. 
Controlled  data  flow  over  these  connections  is 
fundamental  to  the  (ME2)  enforcement  of  application 
based  security  models.  Our  implementation  of 
connections  requires  the  (ME2 )  to  enforce  strong 
typing  rules  over  the  connection,  as  well  as  data 
and  process  security  rules.  Verification  that  data 
flows  are  maintained  according  to  typing  rules  is 
expected  to  be  useful  for  verifying  certain  types  of 
data  integrity. 

In  the  (ME2)  implementation  of  connections, 
each  connection  has  several  associated  attributes 
whtch  describe  the  size  of  data  that  the  connection 
accepts,  the  type  (e.g.  control,  data,  or  message 
type)  that  the  channel  accepts,  and  whether  or  not 
the  connection  Is  internal  or  external.  In  addition 
the  container  has  data  and  process  security  labels 
that  must  dominate  the  data  and  process  labels  of 
the  sink  before  a  transmission  can  occur.  In  the 
(ME2)  implementation,  the  connections  and  their 
associated  attributes  are  contained  within  a  (ME2) 
data  base  that  has  been  burned  Into  Read  Only  Memory 
(ROM). 

4.3  Source  Stations,  Sink  Stations,  and  Workstations 

At  the  (ME2)  implementation  level,  source  and 
sink  stations  are  the  heads  and  tails  of  data 
queues.  Because  the  (ME2 )  provides 
first-in-first-out  (FIFO)  processing  of  queued  data, 
a  source  station  Is  always  the  queue  head  while  sink 
stations  are  always  the  queue  tall.  Workstation  is 
a  more  general  term  that  refers  to  a  data  depository 
at  which  a  queue  element  (the  sink  station,  the 
source  station,  or  some  other  element)  is 
accessible, 

In  the  (ME2) ,  a  workstation  Is  implemented  as  a 
permanent  entry  within  a  process  node's  local 
descriptor  table.  Effectively,  this  permanently 
defines  the  virtual  address  of  a  workstation.  To 
access  data  contained  at  the  data  depository  (i.e. 
a  particular  queue  element),  application  programs 
access  the  virtual  address  of  the  workstation.  As 
an  analogy,  consider  the  workings  of  a  photographic 
slide  projector.  A  queue  of  slides,  present  in  the 
slide  projector,  are  viewed  individually  by  the 
projector's  movement  of  a  slide  through  the  lens 
path.  In  much  the  same  way,  the  (ME2)  must  make 
individual  containers  visible  at  a  fixed  virtual 
address  for  viewing  by  process  nodes. 

The  descriptor  table  based  memory  management  of 
the  Intel  80286  microprocessor  provides  t.he 
efficient  mechanism  for  making  a  new  queue  element 
visible  at  the  workstation.  Because  the  local 
descriptor  table  is  actually  a  table  of  physical 
addresses  and  access  rights  associated  with  each 
virtual  address,  the  (ME2)  can  efficiently  make  a 
new  queue  element  visible  at  a  workstation  by 
copying  the  physical  address  of  the  queue  element  to 
the  local  descriptor  table  (see  figure  2).  As  a 
consequence,  the  elements  of  a  queue  might  be  at 
many  non-contiguous  physical  memory  segments,  but 
are  viewed,  because  of  the  actions  of  the  (ME2), 
through  a  workstation  at  a  fixed  virtual  address. 


The  (ME2)  implements  application  based 
restrictions  on  workstation  access  according  to  the 
access  rights  declared  for  the  queue.  A  workstation 
may  be  declared  as  read  only,  write  only, 
read-write,  or  no  access.  (ME2)  provides  these 
access  restrictions  by  writing  the  applicable  value 


figure  2.  Intel  80286  Domain  Isolation 
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to  the  local  descriptor  table  entry  associated  with 
the  particular  workstation. 

In  the  (HE2)  Implementation,  because  each  work 
station  of  a  process  node  Implies  a  unique  local 
descriptor  table  entry  for  that  process  node,  the 
number  of  work  stations  Is  physically  limited  by  the 
maximum  number  of  local  descriptor  table  entries 
(approximately  8000).  However,  we  expect  the  number 
of  workstations  to  vary  greatly  based  on  the  Input 
and  output  requirements  of  the  node.  For  example,  a 
node  responsible  for  message  storage  might  segregate 
messages  based  on  data  and  process  security  labels 
and  thus  require  a  large  number  of  workstations, 
while  another  node  might  only  require  one 
workstation  for  an  Internal  data  structure. 

4.4  Containers 

As  previously  described,  a  container  Is  broadly 
categorized  as  either  a  single-level  or  a  multilevel 
Information  structure  that  is  transmitted  over  a 
connection.  Like  the  connections  that  they  are 
transmitted  over,  containers  have  attributes  that 
describe  their  size,  type,  data  security,  and 
process  security  attributes.  Examples  of  container 
types  Include  message  containers,  control 
containers,  and  data  containers. 

In  the  (ML2),  containers  are  Implemented 
according  to  user  configurable  allocations  of 
physical  memory  based  on  container  type  and  size. 
Consequently,  a  container  Is  actually  a  contiguous 
segment  of  physical  memory  that  contains  data  of  the 
type  declared  for  the  container  as  well  as  data  and 
process  security  labels.  Potentially  multilevel 
containers,  such  as  message  containers,  contain  a 
data  and  process  security  label  for  each  Individual 
unit  of  Information. 

The  (ME2)  distributes  containers  to 
workstations  based  on  the  value  of  a  workstation 
attribute  known  as  the  auto-reflll  attribute.  If  a 
workstation  Is  defined  as  an  auto-reflll 
workstation,  the  (ME2)  will  associate  an  empty 
container  with  the  workstation  at  system 
initialization  and  at  any  future  time  that  all 
workstation  containers  have  been  transferred  over  a 
connection.  An  empty  container  is  defined  as  a 
container  whose  contents  have  been  set  to  zero  or 
some  other  Innocuous  value  by  the  (ME2).  At  system 
Initialization,  all  containers  are  empty.  Later, 
used  containers  are  emptied  by  the  (ME2)  and  become 
available  for  reuse  as  they  are  sent  from  the 
application  back  to  the  (ME2), 

4.5  Data  Sensitivity  Labels 

In  (ME2),  data  sensitivity  labels  are 
implemented  with  a  secrecy  component  and  an 
integrity  component.  The  secrecy  component  of  the 
label  provides  up  to  sixteen  hlerarchal  levels  and 
sixty-four  non-hlerarchal  compartments  within  each 
level.  Integrity  types  will,  of  course,  be 
different  among  applications.  Specific  definition 
Is  dependent  on  a  particular  application  based 
security  model.  Two  Integrity  levels,  high  and  low, 
are  supported.  As  mentioned  earlier,  (ME2) 
enforcement  of  strong  typing  rules  Is  also  expected 
to  be  useful  for  verification  of  certain  types  of 
Integrity. 

The  assignment  of  values  to  a  data  sensitivity 
label  differs  depending  on  whether  the  data 
sensitivity  label  Is  for  a  container  or  a 
workstation.  The  data  sensitivity  labels  for 
workstations  are  static.  They  reside  In  the 
read-only  portion  of  the  (ME2)  data  base  and  result 


from  a  system  design  bised  on  a  state  machine 
architecture.  Because  the  system  design  1$  based  on 
Isolating  data  flows  and  processing,  the  set  of 
possible  data  security  labels  that  a  workstation  may 
accept  is  known  pre-runtime. 

On  the  other  hand,  because  containers  are 
reusable,  the  values  for  the  data  sensitivity  labels 
of  a  container  must  be  assigned  as  tho  container  Is 
used.  Initially,  at  the  time  the  (HE2)  provides  a 
container  to  an  auto-reflll  workstation,  the  data 
sensitivity  labels  of  the  container  have  a  value 
known  as  obscure.  That  Is,  the  (ME2)  and  all 
process  nodes  recognize  that  the  container  In 
question  has  not  been  labelled.  Certain  process 
nodes  may  request  the  (HE2)  to  change  the  value  of  a 
data  sensitivity  label  for  a  container  from  obscure 
to  some  other  value.  Tho  (ME2)  will  perform  such  a 
label  change  If  and  only  If  such  a  change  Is 
consistent  with  the  process  security  requirements. 
That  Is,  just  as  only  certain  Individuals  have  the 
authority  to  downgrade  a  military  message,  the  (ME2) 
ensures  that  only  certain  process  lodes  may  change  a 
container  label. 

From  a  (ME2)  Implementation  perspective,  data 
sensitivity  labels  are  always  contained  In  memory 
thit  Is  accessible  only  to  the  (ME2).  Consequently, 
data  sensitivity  labels  are  only  changeable  If  the 
process  node  Is  trusted  and  the  change  is  requested 
through  the  appropriate  (ME2)  service  request. 


4.6  Process  Sensitivity  Labels 

Process  security  requirements  ensure  the 
prevention  of  undesirable  and  potentially 
catastrophic  events  In  an  embedded  computer  system. 
A  general  example  is  the  requirement  that  a  certain 
weapon  system  be  fired  only  after  a  r  juence  of 
controlled  events  has  been  Implemented,  .n  example 
taken  from  military  message  system  domains  is  the 
requirement  that  the  processing  of  more  important 
messages  preempt  the  processing  of  less  important 
messages  or  the  requirement  that  among  equal 
priority  messages,  messages  should  be  processed  In  a 
flrst-in-first-out  (FIFO)  manner. 

The  Naval  Research  Lab  suggests  that  one 
approach  for  enforcing  process  security  requirements 
Is  the  approach  that  is  currently  used  for  enforcing 
data  security  requirements.  Specifically,  the  NRL 
suggests  that  to  enforce  process  security,  a  system 
be  structured  Into  a  set  of  functions  that  affect 
process  security  and  a  set  that  do  not  [3].  By 
verifying  that  the  functions  that  have  the 
capability  to  violate  process  security  do  not 
violate  It  (they  are  trusted),  process  security  can 
be  assured. 

This  approach  Is  the  one  we  have  taken  with  the 
(ME2).  As  a  result,  the  (ME2)  Is  the  function  that 
enforces  data  security  and  process  security.  As 
mentioned,  an  Important  process  security  requirement 
Is  that  the  processing  of  more  important  messages 
preempt  the  processing  of  less  Important  messages, 
and  that  among  equal  priority  Messages,  messages  are 
processed  in  a  flrst-in-first-out  (FIFO)  manner, 
just  as  the  (ME2)  provides  sensitivity  labels  to 
enforce  data  security  requirements,  a  similar  label 
is  used  to  designate  the  relative  Importance  of  a 
message  so  that  process  security  requirements  car,  be 
enforced.  In  the  (ME2),  this  label  is  referred  to 
as  the  container's  'Necessity".  Five  necessity 
values  are  supported  In  the  (ME2).  The  structure  of 
these  values  Is  application  configurable. 

dU}J|JU[  LtiU  III  UI«P  \riLC.  /  • 
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By  assigning  necessity  labels  to  each 
container,  containers  may  be  segregated  according  to 
message  necessity.  This  eliminates  the  need  for  a 
shared  queue  of  multiple  necessity  levels.  As  with 
data  security  labels,  the  (HE2)  uses  the  necessity 
labels  to  restrict  the  flow  of  containers  over 
connections.  The  (ME2)  will  transfer  a  container 
over  a  connection  only  If  the  necessity  label  of  the 
container  dominates  the  necessity  label  of  the  sink. 
Consequently,  the  segregation  of  containers  coupled 
with  the  (ME2)  process  node  preemption  based  on  the 
arrival  of  a  container  at  an  empty  workstation 
provides  assurance  that  the  data  that  has  arrived  Is 
of  greater  Importance  than  current  processing,  and 
that  the  arrival  will  cause  preemption.  This 
enforces  the  process  security  requirement  that 
higher  priority  message  processing  preempt  lower 
priority  message  piocusslng. 

The  other  type  of  process  security  label  that 
the  (ME2)  provides  Is  a  command  label  which  lists 
all  of  the  authorized  (ME2)  commands  that  a  process 
node  can  request.  An  earlier  example  Illustrated 
how  the  command  label  Is  used  to  prohibit  all  nodes, 
except  the  authorized  nodes,  from  changing  tha  data 
security  labels  of  a  container. 

The  final  type  of  process  security  provided  by 
the  (ME2)  Is  denial  of  service  protection.  Denial 
of  service  protection  is  provided  through 
application  configurable  parameters  for  each  process 
node  and  a  TRUMMP  Interval  timer. 

4.7  The  (MEZ) :  A  Summary 

The  Military  Message  Embedded  Executive  ( (ME2 ) ) 
Is  an  executive  which  also  contains  a  security 
enforcing  foundation  based  on  the  data  and  process 
security  requirements  of  ml  1 Itary  message  systems . 
The  key  to  security  In  the  (ME2)  Is  a  state  machine 
architecture  which  divides  the  system  Into  process 
nodes.  Information  Is  stored  in  strongly  typed 
containers  which  are  transferred  over  connections  to 
strongly  typed  workstations.  The  (ME2)  Implements 
traditional  data  security  labels  as  well  as  process 
security  labels.  The  deficiencies,  as  described  In 
[1],  of  SIGMA,  a  security  kernel  for  the  Military 
Message  Experiment  (MME),  do  not  exist. 
Specifically,  (ME2)  provides  the  capability  for 
authorized  downgrade,  Implements  multilevel  objects 
(containers),  and  provides  a  structure  for 
implementation  of  application  dependent  security 
requirements. 


domain  isolation  that  Is  at  the  heart  of  the  (ME2) . 
Specifically,  the  Intel  80286  defines  data 
structures  that  allow  the  microprocessor  to  perform 
firmware  based  domain  switching  In  as  little  as  16 
microseconds,  The  TRUMMP  also  contains  Interval 
timers,  and  Interrupt  controllers. 

Because  the  usual  application  of  the  TRUMP  Is 
intended  to  be  as  an  embedded  processor,  particular 
attention  to  the  expected  operational  environment  Is 
required.  Figure  3  Illustrates  e  sample 
environment.  In  the  figure,  the  TRUMMP  Is  the 
primary  trusted  computer  resource  responsible  for 
sending  and  receiving  military  messages  to  and  from 
the  telecommunications  network(s). 

Figure  3  shows  the  expected  subsystem 
interfaces  that  the  TRUMMP  accommodates.  To  meet 
performance  objectives  and  to  simply  the  external 
Interfaces  to  the  TRUMMP  and  (ME2),  as  figure  4 
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S.  THE  TRUSTED  MILITARY  MESSAGE  PROCESSOR 

When  complete,  the  Trusted  Military  Message 
Processor  (TRUMMP),  pronounced  as  "TRUHMP"  as  In 
playing  Bridge,  will  be  a  militarized  microcomputer 
specifically  designed  to  support  the  Military 
Message  Embedded  Executive  [ (ME2) ]  and  Its 
applications.  Design  objectives  include  high 
performance,  architectural  features  that  directly 
support  (ME2)  functions,  and  minimum  physical  size 
and  weight.  Mil-Spec  and  rugged i zed  versions  will 
be  available.  TEMPEST  and  HEMP  requirements  can  be 
accommodated. 

At  the  heart  of  the  TRUMMP  Is  an  Intel  80286 
microprocessor.  The  Intel  60286  Is  a  high 
performance  16  bit  microprocessor  that  provides  on 
chip  memory  management,  descriptor  based  segmented 
virtual  addressing,  and  physical  memory  addressing 
to  16  megabytes.  These  attributes  support  the 
funct  1  o..a  I  requirements  of  a  military  message 
processor,  From  an  INFOSEC  perspective,  the  Intel 
80286  was  chosen  for  Its  unique  capability  to 
provide  the  type  of  efficient  hardware  enforced 


Figure  3.  Embedding  the  TRUMM 
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shows,  an  1APX-188  component  Is  responsible  for 
polling  and  buffering  data  to  and  from  each  of  the 
serial  channels.  The  1APX-188  communicates  with  the 
TRUMMP  and  the  (ME2)  over  the  Multibus  system  bus. 


6.  CONCLUSIONS  and  FUTURE  PLANS 

This  paper  has  described  the  progress  of 
Magnavox  research  into  the  multilevel  secure 
automated  exchange  of  military  messages,  This  work 
represents  new  approaches  to  "designed  in  security" 
that  are  not  based  on  the  security  kernel  and 
Bell/LaPadula  model  approaches  that  have  dominated 
military  message  systems  and  the  Industry  for  the 
past  fifteen  years.  Instead,  the  approach  Is  based 
on  the  concept  of  a  set  of  communicating  finite 
state  machines.  The  (ME2)  is  an  efficient 
implementation  of  this  concept  that  corrects  the 
security  kernel  and  Bel 1/LaPadula  model  deficiencies 
that  have  been  cited  for  military  message  systems 
through  frequent  use  of  these  traditional 
techniques. 

Beyond  its  security  kernel  alternative,  we 
believe  the  (ME2)  Is  additionally  unique  for  Its 
attention  to  the  process  security  requirements  [3] 
of  embedded  computers.  With  the  annual  maintenance 
arid  development  costs  of  OoO  embedded  computer 
resources  expected  to  exceed  S  40  billion  by  1990 

[3],  we  believe  that  Its  time  to  understand  and 
enforce  the  security  requirements  that  are  unique  to 
these  computers.  Security  In  these  systems  Is  more 
than  protecting  files  from  users.  In  the  (ME2) 
development,  we  have  begun  to  address  these 
requirements.  In  referring  to  these  requirements, 
we  have  used  the  same  terminology  as  the  Naval 
Research  Lab,  process  security  [3]. 

We  are  currently  testing  our  concepts  with 
(ME2)  and  TRUMMP  prototypes  In  our  System  Security 
Engineering  lab.  Our  next  major  milestone  is  the 
evaluation  of  our  development  against  either  TNI, 
TCSEC,  or  some  other  standard  [7],  Beyond  these 
goals,  we  expect  to  address  verification  Issues  In  a 
future  report  [6],  and  to  evaluate  our  concepts  with 
different  hardware  and  different  application 
domains. 
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Abstract.  In  computer  systems  designed  for  high  levels 
of  security  awurnnee,  sensitivity  labels  nre  used  to  protect 
sensitive  data.  As  multilevel  secure  distributed  computer 
systems  increasingly  replace  sensitive  hardeopy  doemnents 
with  softcopies  mid  uuiomate  their  professing,  the  more 
eompreltciwive  mechanism  of  n  security  profile  will  lie 
needed.  We  Illustrate  the  problems  that  security  profile*  will 
address  with  three  popular  hut  rarely  valid  assumptions  alxiut 
labels:  I)  labels  on  data  (ehussillent.ionx)  and  labels  on  people 
or  processes  (elenranees)  nre  drawn  from  the  same  partially 
ordered  set,  2)  labels  are  relatively  simple,  having  only  an 
hiermvliieal  part  and  a  non-bierareliical  part,  mid  :i) 
sensitivity  labels  and  their  associated  rules  sulliee  to  Insure 
correct  handling  or  the  data  so  labeled.  I’l'aclltioners  in  the 
computer  security  community  nre  becoming  aware  of  the 
inapplicability  of  these  assumptions  outside  dr  lined  contexts, 
We  seek  to  increase  that  awareness  and  to  explore  the 
implications  for  future  more  ambitious  systems. 


1.  Overview  and  Definition 

1.1  Introduction.  Institutions  and  individuals  have  a 
need  lo  protect  sensitive  information  from  umm(hori/.ed 
disclosure,  nioililiealion,  degradation,  destruction,  and  misuse, 
while,  at  (lie  same  time,  allowing  those  who  have  been 
identilied  •,«  trustworthy  and  are  so  authorized,  to  read,  write, 
manipulate,  store,  retrieve,  and  selectively  transmit  nr  share 
such  iiifornmlion  according  lo  their  legitimate  needs  to  do  so.1 

in  some  contexts,  documents  containing  sensitive 
information  may  be  identified  as  such  by  simply  attaching 
warning  statements.  A  more  elaborate  scheme  is  to  classify 
information  according  to  sensitivity  and  to  “classify"  personnel 
according  to  trustworthiness,  Only  the  more  trustworthy 
personnel  with  ail  identilied  need  to  knovi  are  allowed  access 
lo  the  more  sensitive  information. 

In  current  government  and  some  commercial  computer 
systems,  tin*  protection  mechanism  may  involve  associating 
with  data,  sensitivity  labels  that  indicate  the  degree 
(hierarchical  level)  of  sensitivity  and  the  ealegorv(ies), 
com  part  ment(s),  or  "subject  nrea(s)“  of  (he  corresponding 
information.  One  sensitivity  label  is  said  to  dominate  another 
if  its  hierarchical  component  is  greater  than  wr  eipial  to  the 
hierarchical  ri>m|xmeiil  of  the  other  and  it.s  set.  of 
compartments  contains  the  set  of  compart  ments  of  the  oilier 
ft,  -l|.  Typically,  in  the  altsenee  of  privilege,  a  secure 
computer  system  allows  data  to  llow  from  one  stilijeel./object 
to  another  only  if  the  sensitivity  label  on  the  recipient 
dominates  the  -sensitivity  label  on  the  sender.  (This  is  a 
necessary,  not  a  sullieienl,  condition.)  For  example,  Secrel- 

1.  Although  tin1  goal  of  uilorumlioa  security  is  lo  pioLecl  injormttlian. 
this  is  usually  uceoiuplisht il  by  protecting  /lain  whose  correct  or 
approximate  interpretation  yields  the  information  deemed  sensitive, 
amt  tilts  in  turn  may  he  achieved  by  controlling  signal*  that  transmit., 
or  patterns  that-  convey,  the  data.  It  is  customary  to  blur  these 
distinctions. 


A/ll  dominates  Conlidoulial-U,  while  neither  is  comparable 
with  Seercl-B/C.  An  untreated  (normal)  process  running  at 
tilt:  llrsl  level  could  receive  data  from  tut  nntrusted  process 
running  at  the  second  level,  hut  not.  vice  versa.  Neither 
process  could  semi  or  receive  from  an  milrustcd  process  at  the 
third  level.  Ait  "object"  (e.g.,  Hie)  containing  data  at  each  <>r 
these  levels  would  have  to  have  an  overall  classlllcatiun  of  at 
least  Seerel- A/B/C.2  In  of  er  words,  the  elassillcatiou  of  a 
tlocuiiicnt  must  lie  at  least,  the  least  upper  hound  of  the 
eliissillcatioiis  of  data  in  the  document. 

The  hierarchy  scheme  is  usually  associated  with 
government  classification  systems  (in  some  communities, 
"ehissilled"  «»  "government,  chtssilletl"),  hut  it  Is  also  used  by 
large  corporations  for  their  proprietary  information.  For 
example,  IBM  elassllles  their  internal  Information  as  Public 
(unclassified),  Internal  Use  Only,  Conlidenlial,  Gotilldelllial 
Restricted,  and  Registered  Confidential  Most  of  the 
following  R  based  on  the  government  classification  program, 
lull,  the  requirements  are  just  as  applicable  In  a  commercial 
and/or  proprietary  program.'1.  r' 

1.2  Markings.  The  classification  of  a  document,  is  not 
the  only  seeiirily-i'elnted  information  needed  to  handle  a 
document  properly.  When  marking  hardcopy  documents,  the 
applicable  ehussilieiit.ion  labels  with  ntodillcrs  must  appear  on 
the  pages  and  portions,  and  all  other  markings  may  lie  placed 
on  a  "title  page",  which  must  also  he  marked  with  the  overall 
classi licnUon  Blind.  The  other  markings  (notations  ami 
statements)  are  usually  referred  to  as  the  title  page  markings. 
Tlmse  include  warning  notices,  information  about-  control 
channels  fur  dissemination,  clnssilicntiun  authority, 
deehussilieation  dale.  etc. 

Of  course,  the  title  page  should  also  have  a  title  and  other 
means  (Document  Number)  of  identifying  the  document.  The 
title,  itself,  must  lie  labeled  with  a  classilicittion  label  ami, 
wherever  possible,  lie  uiiclassilied. 

The  Industrial  Security  Manual  for  Safeguarding 
Classified  Information  (ISM)1’  requires  the  following 


2  Unfortunately.  in  computer  senility,  assuming  nil  "object."  is  only  a 
piissive  object  is  problcmnt i»-,  (liven  ;i  string  of  bits  in  a  computer,  it 
is  «li llic-iilt .  at  best,  t<»  determine  whether  string  is  potentially  data 
or  process  or  licit  it .  In  a  BclI-nmMm-Pudulndikc  computer  senil  ity 
model  i'jj.  an  executable  "object",  when  executing,  is  presumably  a 
subject,  or  at  least  a  surrogate  thereof,  and  thus,  ;ls  a  string  of  bits,  is 
both  data  and  process  |l*J.  13]. 

3.  'I’ll  esc  are  the  hierarchical  levels  suggested  in  "(food  Security  Practices 
for  Informal  ion  Ownership  and  Classification,1’  (JMO-2705‘0,  IBM, 
Nov.  lfl>?l}.  Wr  heli'*ve  these  suggestions  are  based  op  IBM’s  pnwt-ice. 
We  also  consider  primarily  sensitivity  to  disclosure  rather  than  to 
destruction  or  mudiliention. 

5  'l’lie  emphasis  in  information  securily  programs  is  usually  placed  on 
the  upper  levels  of  a  hierarchical  system,  its  is  appropriate.  However, 
there  is  a  large  amount  of  information  that  is  not  identified  by  nay 
classification  scheme  that  still  requires  protection  because  of  some 
legal,  business,  nr  ethical  requirement. 

(>.  Dot)  5'J20.‘J-*M.  September  11187 
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markings  "for  all  classified  information,  regardless  of 
the  form  in  which  it  appears":' 

1.  Identification  Markings. 

a.  Name  and  address  of  facility  responsible  for 
preparation  of  material. 

1>.  Date  of  preparation. 

•J.  Overall  Markings.  (Classification  of  document.) 

;i.  Page  Markings. 

■I.  Component  Markings.  (Knelt  appendix,  attachment, 
etc.) 

fi.  I ’or lit >n  Markings.  (Section,  paragraph,  illustration, 
photograph,  llgnre.  graph,  ole.) 

(i.  Subject  and  Title  Markings. 

7.  Downgrading/Deehissillrntion  and  "(Jlassllled  by" 
Markings. 

s.  Additional  Markings,  (if  applicable) 

a.  RKSTRK.TKD  DATA  Notation. 

b.  FORMKRLV  RKSTRlGTKD  DATA  Notation. 

e.  INTKI.I.IGKNGK  SOURCKb  OR  MKTIIODS 
Notation. 

d.  DISSKMINATION  AND  RKI’RODUCTION 
NOTICKS. 

e.  KORKION  (iOVKRNMKNT  INFORMATION. 

f.  THIS  DOUUMKNT  CONTAINS  NATO 
INFORMATION. 

For  our  purposes,  it  is  helpful  to  reorganize  the 
above  as: 

A.  Classification  Labels  (2-tl  above) 
li.  Notations 

1.  Warning  Notices 

2.  Instructions 

Control  Channels  (Dissemination) 

(3.  Authority  Statements 

1.  Classification  Statements  (Classified  by 

...) 

2.  Declassification  Statements 
(Uegrade/downgrade/declassify  to  - 
by  <date/event>) 

D.  Ownership  (Must  approve  dissemination  or 
justify  classification) 

1.3  Security  Profiles.  Sensitivity  labels  provide  at 
most,  the  information  in  A  above,  lint  no  piece  of 
Infonmiiirm  in  a  Marking  is  superlluons.  For  every 
component  of  a  Marking,  t  here  is  some  action  that  may  be 
taken  on  or  with  the  hardcopy  document  that  requires  that 
component,  (possibly  in  conjunction  with  others)  in  order  to 
maintain  security  and  ultimately  to  prevent  unauthorized 

7.  Ibid..  1 Ml.  p.  M. 


disclosure.  (We  provide  examples  below.)  Automating  these 
actions  in  »  secure  computer  system  will,  therefore,  require 
more  information  than  is  contained  in  sensitivity  labels.  This 
iiiformutfcn.  In  a  computer  system,  we  refer  to  as  a  security 
profile .*  (The  reader  is  warned  that  where  we  use  the  term 
"security  label",  we  always  mean  a  complete  security  label, 
i.c.,  a  security  profile ,  not  a  sensitivity  label.) 

Definition.  The  security  profile  of  a  softcopy  document 
is  the  softeop”  equivalent  of  the  complete  set  of  Markings  for 
the  corresponding  hardcopy  document.4 

1.4  Problems  with  Hierarchical  Levels.  For 

classified  Information,  possible  U..S.  hierarchical  levels  arc: 

I  Inclassilled  <  Confidential  <  Secret  <  Top  .Secret,  possible 
non-U.S.  Iilerarchical  levels  are:  Unclassified  <  UestiieUsl  < 
Confidential  <  Secret  <  Top  Secret.  Tile  U.S.  traitsiation  of 
"Restricted"  is  typically  "Handle  ns  Ooulidonl.ini"  (label  and 
clearance  required  for  [read)  access)  even  thougli  the  physical 
storage  requirements  may  be  more  akin  to  FOUO  (see  heiow), 
Some  countries  have  only  two  levels:  Secret  <  Top  Secret.10 
Therefore,  any  IhS,  Confidential  doeunient  (In  whatever 
medium)  provided  to  those  countries  might  have  in  be 
upgraded  (in  their  possession  or  access)  to  an  hierarelilciil  level 
(tlielr  Secret)  equivalent  to  (V  l.S.)  Secret.  Of  course,  it  would 
also  retain  its  U.S,  Conlhleiitial  label.  The  actual 
equivalences  and  translations  of  labels  is  per  the  security 
agreements  between  the  countries  Involved.  Automating  this 
nmy  require  a  Multlnct  Gateway  (MNG),  a  Trusted  Network 
Interface  (TNI),  or  Trusted  Computing  liase  (TCR)  to  "know" 
such  security  agreements, 

A  label  t  hat  is  not  really  part  of  the  U.S.  clnssiliralioii 
scheme  is  "For  Olliclnl  Use  Only".  Ahhrevinlcd  as  "(KOUO)" 
for  portion  (paragraph)  marking.  FOUO  is  used  for 
information  that,  is  not  classified  lull  still  requires  some  degree 
of  protection:  it’s  for  oliicial  business,  not  for  general 
distribution  or  publication.11-  10  Some  documents  specify  t  hat 
nuelassilied  extracts  must,  lie  marked  "For  Oliicial  Use  Only", 
An  unclassified  document-  that  contains  portions  extruded 
from  a  classified  OOMSKC  document,  where  all  portions 
extracted  were  marked  "(U)",  must,  he  marked  "For  Oliicial 
Use  Only",  while  the  extracted  port'ons  must,  be  marked 
"(FOUO)".13  (See  tig.  j.)  in  a  secure  automated  iulbrmtition 
system  (AIS),  this  means  Hint  extracting  a  labeled  portion 
may  require  changing  tin-  label  of  that  portion  when  it-  is 
imported  into  another  lile  ami  changing  the  security  projilc 
of  the  receiving  till-,  even  when  the  receiving  lile  remains 
"tineltissilied".  Since,  by  delinilion,  the  security  profile  of  n 
document  include',  all  markings,  the  insertion  of  a  labeled 
[K>rtion  constitutes  a  change  in  t  he  security  profile ;  the  point 


g.  Woodward  [  I  -1 .  10]  exploits  l  ie-  dual  nature  of  sensitivity  labels:  (1) 
ssiisitivity  iwl'cntor  and  I'J)  Mandator  y  Acres.-,  Com  rot  Label.  As 
separate  labels,  the  latter  must  dominate  the  turnin'.  Itolli,  however, 
are  "sensitivity  labels",  not  security  prnjiles 

It.  This  delinilion  nssuiues  that-  lnhert-nl  in  any  portion  marking  is  an 
iudieatiou  of  wlml  portion  tin:  marking  applies  to. 

1U.  b  g  ,  Finland.  Sweden  lias  tin*  one  word  "llemlig"  (Secret},  which  may 
be  trouudrd  try  a  double  red  border  (Top  Heeret).  Haiti  Inis  only 
Conti  Jcntial  ruid  Secret. 

1 1.  Some  agencies  just  say  "Otiicial  Use  Only"  nut  "(Ol !())". 

1'.'.  FOUO  could  Ire  used  as  an  added  label  for-  classified  iiirorinalion,  but 
sucti  us,-  would  Ire  superlluons:  etassitled  information  is,  try  dettnilion, 
for  ollieial  use  only,  i.e.,  need-lo-ktiow. 

Id.  From  a  pructiral  standpoint,  FOUO  could  tie  |rositiom-d  between 
Unclassified  mid  Confidential  in  tire  U.S.  Iiii  rnrchy;  however,  it's  more 
u  subset-  of  Uncle.-.-. hied  than  a  separate  level. 
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here  Is  that  the  overall  document  marking  must  change  as 
well.  As  we  shall  sec,  such  extraction-import  problems  tend 
to  be  more  difficult  and,  ipso  facto ,  more  serious,  with  higher 
levels  of  classification. 


Figure  1.  Receiving  file  remains  unclassified,  but 

markings  on  imported  portion  and  on  the 
file  must  change. 


Also,  ilcchiNsUied  Information,  marked  or  unmarked,  must 
still  be  protected;  it’s  not  for  public  release,  unless  so 
authorized  by  the  agency  responsible  for  it.  By  unmarked,  we 
mean  it  Is  not  apparent  that  It.  was  once  classified.  If  It  is 
uncInsslHed,  but.  not.  releasable  Urtlie  public,  there  obviously 
needs  to  be  some  Indication:  e.g.,  "For  Official  Use  Only  or 
“Limited  Distribution". 

2.  Erroneous  Assumptions, 

One  way  to  Illustrate  some  of  the  problems  that  security 
projiten  will  address  is  to  consider  three  popular  but  rarely 
valid  assumptions  about  labels.  We  refer  to  these 
assumptions  ns  El.A  1,  2,  and  3.  "ELA"  (pronounced  "Ella") 

—  "Erroneous  Label  Assumption". 

Erroneous  Label  Assumptions: 

(  ELA  1  )  Sensitivity  labels  on  data  (classification) 
and  on  users  and  their  processes 
(clearances)  are  drawn  from  the  some 
partially  ordered  setj 

(  ELA  2  )  Security  labels  are  relatively  simple,  having 
only  an  hierarchical  part  and  a  non- 
hierarchical  part  (partially  ordered  by  set 
Inclusion); 

(  ELA  3  )  Sensitivity  labels  and  their  associated  rules 
i suffice  to  Insure  correct  handling  of  the 
data  so  labeled. 


Whether  these  ELAs  are  erroneous  or  rather,  if  you  will, 
how  erroneous,  depends  on  context,  he,,  the  demands  placed 
upon  a  given  AIS.  We  are  not  saying  that  the  computer 
security  community  as  a  whole  Is  unaware  of  problems  with 
these  assumptions.  Rather,  we  hope  to  increase  that 
awareness  and  believe  this  is  essential  as  the  demands  cm 
secure  AIS  increase.  Finally,  the  above  assumptions,  even 
when  erroneous,  are  sometimes  conceptually  useful 


simplifications,  when  focusing  on  other  security  mechanisms. 
But  not  even  Dorothy  could  remain  forever  In  Kansas.  We 
propose,  Instead,  to  tell  the  truth  and  nothing  but  the  truth. 

Notice  we  do  not  propose  to  tell  the  whole  truth.  An 
exhaustive  treatise  on  the  way  security  profiles  and 
clearances  really  work  would  be  longer  than  the  Greater 
Armageddon  phone  book  and  duller  than  tofu.  Such  a 
treatise  might  also  be  classified.  Nevertheless,  wc  provide 
sufficiently  detailed  examples  to  bring  home  the  most 
outstanding  and  Interesting  (not  to  say  amazing)  ways  In 
which  each  of  the  three  assumptions  above  fails,  singularly 
and  collectively. 

Not  surprisingly,  the  three  ELAs  are  related.  After  all, 
they  provide  three  views  on  why  secure  AlS's  will  need  to  use 
security  profiles,  Thus,  If  a  real  security  label,  one  that 
suffices  to  Insure  correct  handling  of  data  so  laboled  (In  other 
words,  a  security  profile),  Is  complex,  contrary  to  ELA  2, 
then  the  simpler  mechanism  of  a  sensitivity  label  dons  not 
suffice,  contrary  to  ELA  3. 

2.1  (  ELA  1  )  Sensitivity  labels  on  data  (classification) 
and  on  users  and  their  processes  (clearances) 

are  drawn  from  the  some  partially  ordered  set. 

2.1.1  Clearance  &  Sensitivity  Labels.  The  degree  of 
trust  and  degree  of  sensitivity  markings  ant  usually  expressed, 
within  an  hierarchical  scheme,  with  the  same  labels: 

Clearance  Label  •*  Classification  Label.  E.g.,  a  Top  Secret 
clearance  Is  authorized  access  to  Top  Secret  information, 
Because  of  the  hierarchy  scheme,  the  higher  clearance  level 
can  also  access  (road)  lower  classification  level.,,  hut  flic,  lower 
clearance  level  cannot  access  (read)  higher  classification  levels. 

2.1.2  Clearance  Labels.  However,  life  would  lie  dull 
without  exceptions.  Clearance  Levels  can  be  modified  l.y 
labels  that  nave  no  equivalent  classification  labels,  For 
example,  a  clearance  can  be  modified  as  an  Interim  clearance, 
(We  think  youV  OK,  and  you  can  have  some  limited  access, 
but  not  to  the  good  stuff  until  we  finish  checking  you  out.) 

A  poison  with  an  Interim  Secret  clearance  cannoi  access 
information  classified,  under  the  authority  of  the  Atomic 
Energy  Act,  as  Restricted  Data  (HD)  or  Formerly  Restricted 
Data  (ERD),  but  a  person  with  either  a  Secret  or  interim  Top 
Secret  clearance  can  access  both  types  of  Information  at  the 
Secret  Level  or  lower  [7].  DOE  o031.2  (Chapter  1,  Section  3) 
permits  a  very  restricted  form  of  interim  access  authorization. 
According  to  a  reliable  DOE,  source,  DOE  does  not  recognize 
interim  clearances.  But  the  DoD  dues,  Hence,  It  appears  that 
a  person  with  an  interim  TS  clearance  might  be  granted 
access  to  S-CNWD1  (a  subset  of  RD)  by  the  DoD.  Whether 
this  actually  happens  we  cannot  say.  The  dear  and 
important  point  here  is  that  usually  no  label  on  a  classified 
document  specifies  whether  a  person  with  an  Interim 
clearance  can  access  the  document;  be.,  there  is  no  ‘Interim 
classification  label  corresponding  to  an  Interim  clearance. 
There  might  be  a  r  tatlon  that  prohibits  Interim  access, 
however.  (See  Sec..^n  2.3,2  and  the  Appendix.) 

Similarly,  persons  with  contractor-generated  confidential 
clearances  cannot  have  access  to  classified  foreign  government 
Information,  RD,  FRD,  or  ACDA  (Arms  Control  and 
Disarmament,  Agency)  classified  Information.  Again,  there  is 
no  contractor-generated  confidential  classification  level. 

These  situations  are  handled  by  other  administrative 
procedures;  ju3t  learn  the  rules — unless  "you"  arc  a  computer 
system. 
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Tho  new  Limited  Access  Authorizations  (LA, As)  that  are 
now  issued  to  Immigrant  aliens  and  foreign  nationals  impose 
very  strict  access  and  nced-to-know  limitations.  An 
individual's  access  under  ail  LAA  must  be  determined  on  a 
ease-1), v-cnse,  almost  document-liy-doeiunent,  basis.  In  effect, 
there  are  no  clearances  for  non-(U.S.j  citizens,  only  access 
authorizations  forspeeille  purposes.  A  noncitizen  contractor 
employee  could  require  government  authorization  for  access 
tospecilie  information,  ns  determined  by  noed-to-know  based 
on  job  requirements,  for  a  specific  contract  only. 

2.1.3  DOB  Example.  The  Department  of  Energy 
(DOB)  uses  class!  Ilenlhm  labels  tlmt  arc  not  identical  with 
clearance  labels.1'1  From  the  following  table,  clearances  ami 
cliissilleations  clearly  dilfer  at  least  In  mime. 


Table  1.  Source)  DOB  5331.2/11-13-80. 


Clearance 

Highest  Classification  (Road) 
Accesses  Permitted 

(J-seltsilive 

Top  Secret  KD,  FRD,  Ai*  NSI 

Q-noiisensitivt: 

'Pop  Secret  FRD  A’  NSI 

Secret  RD 

Top  Secret 

'Pop  Scm»(  NSI  &  KUD 

L 

Secret  NSI  X  FRD 

Coitlidcnlinl  RD 

Secret 

Secret  Ns|  ,V  FRD 

Q(X) 

iSeerel  RD 

(its  sjreeilieti  ill  Die  ntteess  permit) 

L(X) 

(•olllidellli.'ll  RD 

(iis specified  in  the  ac'ccss  permit) 

We  illustrate  the  accesses  |H>rinittci|  with  various 
clearances  in  IlguiT  2.  Of  the  lliree  clearances  Q-Sensitive, 
Top  Secret,  and  Secret.  each  ran  l>c  described  in  the  usual 
way  by  a  level  ami  a  set  of  comparl -nieiilo.  Two 
elearanees  tj-non, sensitive  and  I,  however,  ennnot  be  so 
described.  Titus  0 Icara nres  ami  classifications  differ  biolv 
tlian  in  name. 


TS 

TS 

TS  | 

s 

s 

s  | 

C- 

t; 

V  j 

Hi)  ritl)  IS’sl 

a,  Q-Scmdtlve 


TS 

TS 

s 

s 

s 

r 

c; 

V 

lil>  I  HI)  NSI 
b.  Q-Nonsennltlve 


c.  Top  Secret 


it.  L 


e.  Secret 


Figure  2,  Some  DOE  clearances  are  not  just  a  level 
with  compartments. 


Neither  the  ISM  nor  DOF  5631.2  is  transparent. 

According  to  our  DON  source,  the  distinction  between  QS  and 
QN  is  largely  irrelevant.  Mast  people  neither  know  nor  care 
which  Q  clearance  they  have,  The  difference  is  not  in  the 
background  investigation  done,  but  who  did  it:  an  Office  of 
Personnel  Management  (OPM)  investigation  can  yield  a  QN 
clearance;  a  Q.S  clearance  requires  the  Flil.  Since  the  Walker 
case,  the  situation  is  even  simpler:  DOE  Branch  Chiefs  and 
alx>ve  get  QS;  everyone  else  gets  QN.  (We  infer  that.  Branch 
Chiefs  and  alxive  have  had  FIJI  investigations.)  The 
operational  difference  between  QS  mid  QN  is  not  whether  TS 
access  is  granted,  but  how  often.  (Imagine  trying  to  automate 
this.) 

Consistent  with  Tnhic  I,  we  have  also  been  assured  that 
the  difference  between  QS  and  QN  is  unimportant  because 
"DOE  doesn’t  generate  (small  grain  of  sail  here)  TS-ltD." 

Any  TS-ltD  doeunu  lit.  is  almost  surely  a  compilation  of  if  D 
(Secret  or  below)  with  data  that  was  already  TS  for  some 
other  reason.  The  portion  markings  make  clear  how  the 
amalgamation  was  formed.  DOK  does  not  do  portion 
marking  of  strictly  HD  documents. 

The  DOK  has  to  distinguish  between  RD/FRD 
information  classified  under  the  authority  of  the  Atomic 
Energy  Act  and  NSI  (National  .Security  Information)  classified 

under  Executive  Orders.  You  ligurc  it  out . unless  "you"'  are  a 

computer  system.  DOE  also  has  to  protect  Unclassified 
Controlled  Nuclear  information  (UONI).  The  mmparallells'i) 
between  clcnrnnee  and  cliLssilieation  labels  is  caused  in  part  l>y 
the  overln  pping.  lion  hierarchical  nature  of  these  classification 
requirements  wliich  brings  us  lo  the  next  NBA. 

2.2  (  El, A  2  )  Security  labels  are  relatively  simple 
with  an  hierarchical  part  and  a  non-hierarchicul  part 
(partially  ordered  by  sot  inclusion). 

2.2.1  Nonhicrarchical  Systems.  Unclassified  National 
Security-Related  (ilNS-R)  (pronounced  "unser")  information  is 
a  broad  category  of  information  that  is  considered  to  he 
tmclnssilied  hut  sensitive  and,  in  the  interests  of  national 
seciirily,  slioiild  lie  pinteeted,  especially  when  being  processed 
in  A  IS  or  leleetnniuuiiiratinns  systems  tlmt  are  vulnerable  lo 
inonitoring  b.v  unfriendly  mlci'eaUs.  Tltere  is  no  label  for 

1 1  Ns- It  infnruintion  but  perhaps  there  slioiild  he  in 
computer  systems.  Snell  information,  of  course,  can  have 
oi  lier  labels  or  aolal ions  such  as  Proprietary,  FOUO,  etc.  • 
some  of  which  could  he  hierarchical.  Large  proprietary  or 
private  systems  could  lie  considered  equivalent  to  "UNS-R 
Systems". 

Level  Modifiers.  In  many  cases,  the  level  label  must  be 
modilied  to  show  owner  or  added  sensitivity  of  the 
information: 

2.2.2  Ownership  Modifiers.  In  friendly  foreign 
relations,  whereby  countries  or  international  part, 
organizations  exchange  elussilied  information,  the  document 
must  identify  ‘lie  owner  of  the  information.  For  example,  if 
(lie  IBS.  should  b>'  provided  with  a  United  Kingdom  Secret 
document,  the  level  label  should  indicate:  UK-Secret.  NATO 
iloeuinenl.s,  for  another  example,  must  he  labeled  COSMIC 


M.  I 'nil' I  iUonei  >  iut<]  even  more  so.  researchers,  in  Dol)  secure  emnpuler 
systems  slioiild  iiol  object  to  a  I)C)E  example.  Members  of  one 
community  need  to  lie  aware  of  the  practices  of  the  other.  Moreover, 
we  tielieve  tire  trend  is  townrd  multilevel  secure  distributed  systems  of 
once  isolated  eouifniniilies  dial,  wilt  eonuumiieate  with  each  other 
'.hrotizh  M  ui li i let-  C.nleways. 
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Top  Secret,  NATO  Secret,  NATO  Confidential,  or  NATO 
Restricted,  :is  applicable.  Notice  that  modillers  may  lx? 
inconsistent:  'Pop  Secret  is  modilleil  bv  "COSMIC",  not 
"NATO".1'1  It’s  a  little  like  learning  an  irregular  verb  -unless 
"you"  are  a  computer  system. 

A  modified  level  does  not  necessarily  transfer  when  a 
document  portion  is  copied  into  another  document.  For 
example,  if  NATO  Secret  information  is  copied  into  a  U.S. 
document,  the  U.S.  is  obliged  to  classify  the  document  Secret 
(at  least),  but  not  .NATO  Secret.  Instead,  the  U.S.  document 
must  bear  tlie  warning  notice:  'Tills  DOCUMENT 
CONTAINS  NATO  INFORMATION";  and  the  portion 
containing  the  NATO  information  must  he  labeled  "(NATO- 
S)".  (See  llg.  3.)  To  import  a  portion  from  one  "lile"  into 
another,  you  learn  the  rules  -unless  "you"  are  a  computer 
system,  Such  rules  involve  more  than  sensitivity  -which  is 
our  linal  FLA. 


Figure  3.  Importing  Secret  Portion  from  NATO  File 
into  U.S,  Secret  File. 


2.3  (  ICLA  3  )  Sensitivity  labels  and  their 
associated  rules  xujjire  to  insure  correct  handling 
of  tlie  data  so  labeled. 

2.3.1  Sensitivity  Modifiers.  As  some  of  the  previous 
examples  illustrate,  sensitivity  labels  by  themselves  do  not 
sullice  for  a  variety  of  reasons,  such  as  the  inclusion  of  various 
modiliers,  document  notations,  and  t  he  interdependencies  of 
ownership  and  classification  authorities.  Frequently, 
classification  labels  must  be  modi  lied  to  show  that  the 
information  is  extra  sensitive  and  requires  additional 
protection. 

In  the  COMSEC  world,  encryption  keys  arc  considered 
ultra-sensitive.  Material  containing  a  key  must  he  labeled 
with  the  appropriate  classification  level  modified  by  a 
UR\  I ’TO  label: '  Top  Secret  Crypto,  Secret  Crypto,  or 


15.  DIAM  05-10,  itfiii  3-07:  "COSMIC!  is  :i  caveat-  ripplied  to  NATO  TOP 
SKCHKT  (iocuim'tii*.  Tlx-  raveni.  denotes  ivquimtumlH  for  specific 
piweduro*  in  handling  and  tlissenii  anting  documents  so  murk <*<1. 11  Our 
description  clminr  twines  prmrl  ice. 


Confidential  Crypto.  This  requirement  even  extends  to 
unclassified  material:  Unclassified  Crypto  and  For  Olllcial 
Use  Only  Crypto.  And,  of  course,  the  requirement  applies  to 
all  marking  levels:  document,  page,  and  portion:  e,g„  "(U- 
Crypto)". 

Restricted  Data  (RD)  is  another  label  that  modifies 
classification  labels.  Moreover,  this  label  indicates  both 
ownership  and  .sensitivity.  Restricted  Data  is  applied  to 
information  classified  under  the  Atomic  Energy  Act,  and  thus 
"owned"  by  DOE —even  if  it  is  also  proprietary  to  and 
“owned"  by  a  contractor.  Ill)  also  indicates  tlmt  the 
information  is  extra  sensitive  and  requires  additional  access 
restrictions.  The  same  is  true  for  Formerly  Restricted  Data 
(FRD).  RD  and  FRD  modify  not  only  docunu  ut  and  page 
laliels,  but  also  portion  labels:  TS-lli),  S-RD,  (MU),  TS-ERD, 
S-FIll),  and  C-F11D.  There  Is  no  unclassified  RD  or  FRD. 

As  previously  mentioned,  however,  there  is  an  Unclassified 
Controlled  Nuclear  Information  (UCNI)  label,  (irnornlly,  RD 
is  physics,  and  UCNI  is  facilities  and  operations,  UCNI 
(Section  118  of  the  Atomic  Energy  Acl)  is  n  Congressional 
resjionsc  to  the  fact  tlmt  OUO  provides  no  legal  .standing  in 
resisting  a  Freedom  of  Information  Act  request.  UCNI 
protects  sensitive,  hut  unclassified,  Information  about  facilities 
and  operations  that  would  previously  have  been  marked 
OUO. 

A  subset  of  RD  is  Critical  Nuclear  Weapons  Design 
Information  (CNWDI).  CNWDI  is  always  labeled  'fop  Secret 
Restricted  Data,  Secret  Restricted  Data,  or  Confidential 
Restricted  Data.  At  the  document  or  page  ievel  of  marking, 
there  is  no  label  for  CNWDI;  there  is  a  CNWDI  notation 
required  on  the  document. 1,1  (More  on  notations  later.) 
However,  CNWDI  can  be  used  as  a  label  to  modify  clearance 
labels.  A  person  can  be  cleared  TS-CNWDI;  i.e.,  lias  a  TS 
clearance  with  a  CNWDI  access  authorization  (and  briefed). 
There  is  a  formal  access  authorization  procedure  that  must  he 
completed  prior  to  a  person's  having  access  to  CNWDI.  Thus 
one  might  understandably  infer  the  hierarchy;  FRD  <  RD  < 
N.  In  fad--,  in  the  subset  sense,  FIR)  <  RD  mid  N  <  RD, 
but  FRD  and  CNWDI  are  generally  incomparable.  According 
to  our  source,  DOE  tra use lassi lies  RD  to  ERD  when  it  needs 
to  be  shared  with  foreign  pari  tiers  and  Irnnselnssilies  HI)  to 
CNWDI  when  it  needs  to  he  shared  with  the  Dol).  Since 
FRI)  does  not  preclude  access  by  Dol)  (Dol)  has  "tons"  of 
ERD).  we  infer  that  CNWDI,  like  HI),  precludes  access  by 
foreign  nationals. 

ATOMAI,  r  another  label  associated  with  Restricted  Data 
and  Formerly  Restricted  Data.  ATOMAI,  is  an  exclusive 
designation  used  by  NATO  to  identify  Restricted  Dutaor 
Formerly  Restricted  Data  information  released  by  the  U.S.  to 
NA'l’O.  Therefore  there  Inis  to  lie  a  method  for  translating 

RD  or  FRD  to  ATOMAI.:  TS-RD  - - -  COSMIC  TS- 

ATOMAI «;  S-RD  * - ►  NATO  S-ATOMAI,. 

In  message  trallic,  the  "Unclassified"  label  ran  be  modified 
by  EFTO,  which  stands  for  Encrypted  For  Transmission  Only 
(but  can  be  stored  in  plain  text).  Apparently,  you  have  to 
explain  why  unclassified  information  is  taking  up  space  in  a 
classified  environment.  EFTO  can  also  act  ns  a  reminder  that 
the  plain  text  could  serve  as  a  source  for  cryptanalysis. 


10.  At  tin-  pen iuu  gramihiriiv  (paragraphs,  Hr,),  portion  labels  must  be 
imidilied  With  the  CNWDI  label  "(N)":  (TS-UDj(N),  (S-R1))(N),  or  (C- 
RI))(N).  "N“,  however,  appears  to  lie  an  artifnrl  or  the  ISM  not  used 
by  the  DOE. 
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Some  other  labels  that  may  be  used  to  modify 
classification  labels  Include;  NOCONTRACT,17 
PROPRIETARY,18  and  LIMDIS.'9 

Compartments  usually  have  access  labels  that  modify 
classification  labels  that  modify  classification  labels.  Special 
Access  Programs  (SAPs),  Special  Access  Required  (SAR) 
programs,  and  Sensitive  Compartmented  Information  (SCI) 
programs  usually  have  code  words  or  other  designators  that 
modify  the  classification:  Top  Secret/codeword  or  Top 
Secrot/codeword/codeword/  •  •  ■  ,  where  each  Instantiation 
of  "codeword"  is  distinct.  Usually,  these  markings  are  either 
classified  or,  if  unclassified,  considered  very  sensitive,  and 
protected  accordingly.  Hence,  no  samples.20 

NOFORN  is  a  label  modifier  that  is  sometimes  used  (e.g., 
Secret-NOFORN),  and  stands  for  No  Foreign  Nationals. 

When  NOFORN  Is  used,  the  document  should  be  marked 
with  some  notation  that  specifies  that  access  Is  limited  to  U.S. 
citizens  and  exceptions  must  be  approved  by  such-and-such 
agency.  Other  possibilities  are  the  exclusion,  inclusion,  or 
both,  of  a  group  of  nationals.  For  inclusion,  the  group  may 
consist  of  one  country;  c-.g.,  NOCONTRACT/REL 
AUSTRALIA."1 

The  lahcl  modi  Her  WN1NTISL  is  sometimes  used  to  label 
information  subject  to  the  warning  notation  "Warning  Notice 
Intelligence  Sources  or  Methods  Involved."  When  used,  this 
modifier  is  usually  at.  the  portion  level  (granularity);  e.g.,  (S- 
WN1NTEI.). 

The  relationships  between  compartmented  classification 
labels  and  clearance  labels  can  be  very  complicated.  (See 
Appendix.)  Compartmentullzatlon  is  consistent  with  noed-to- 
know.  It  helps  prevent  alt  but  the  most  trusted  from  getting 
the  big  picture.  In  the  commercial  world,  compartments 
could  be  considered  equivalent  to  separatlon-of-duties 
requirements. 

2.3.2  Notations.  Notations  are  document  modifiers, 

They  place  some  warning,  restriction,  or  explanation  on  a 
document.  Notations  are  not  labels  or  label  modi  fie  re  per  se, 
There  is  no  such  thing  as  Secret/Notatlon,  The  notation 
must  appear  once  on  the  document,  usually  on  the  cover 
and/or  title  page,  and  "merely"  provides  additional 
instructions  on  how  the  document  Is  to  be  protected.  (This 
poses  problems  for  computer  systems.)  Some  notations, 

17.  Not  relcuaklc  to  contracton/coniulumts  no  matter  what  their 
clearances. 

16.  Proprietary;  Government  does  not  own  the  information.  Approval 
must  be  obtained  from  owner  for  further  dissemination. 

10.  Limited  Distribution:  Distribution  is  limited  to  some  specified  control 
channel  or  program.  LIMDIS  should  be  accompanied  by  some 
notation  that  specifies  what  distribution  is  acceptable, 

20.  Nor  con  we  oiler  examples  of  codewords  that  are  no  longer  used.  To 
do  so  might  result  in  this  document's  being  dusified.  While  we  are  on 
the  subject  of  who-huh-what-labell,  there  exist  compartments  that  we 
can  or  could  mention,  that  have  always  been  unclassified  and  whcee 
meaning  we  now  can  or  could  provide,  although  at  one  time  their 
meanings  were  classified.  But,  white  we  can  discuss  such 
compartments  and  their  meanings  in  an  unclassified  document,  if  we 
were  to  do  so,  we  might  not  be  permitted  to  indicate  that  their 
meanings  were  once  classified.  The  fact  that  the  meaning  of  s  specific 
compartment  has  been  declassified  tends  to  be  classified  or,  at  least, 
sensitive. 

21.  We  are  unaware  of  any  one-country  exclusion  group.  However,  as  an 

(hypothetical)  example  with  (real)  labels:  NOCONTRACT/REL 
AUSTRALIA/  NEW  ZEALAND/  UNITED  KINGDOM  could  be 
upgraded  to  the  more  reetriclive  NOCONTRACT/REL 

AUSTRALIA/  UNITED  KINGDOM.  (Such  an  upgrade  could  be 
driven  either  by  a  change  in  the  document’s  contents  or  by  external 
events.) 


however,  ore  specifically  required  in  addition  to  certain  label 
modifiers.  If  data  or  Information  Is  extracted  from  a 
document  to  which  such  a  notation  applies,  then  the 
notatlon(s)  must  accompany  the  extraction.  Some  of  the 
current  notations  required  by  the  ISM  are  as  follows;52 

(a)  Restricted  Data  requires  the  following  notation  on  the 
containing  document; 

RESTRICTED  DATA 

This  material  contains  RESTRICTED  DATA 

as  defined  In  the  Atomic  Energy  Act  of  1051. 

Unauthorised  disclosure  subject  to 
administrative  and  criminal  sanctions, 

(d)  The  following  Notice  that  reproduction  of  any  portion 
of  a  document  Is  absolutely  prohibited  without  permission 
may  require  knowing  a  chain  of  command-— which  might, 
prove  difficult  for  a  computer  system: 

REPRODUCTION  REQUIRES 
APPROVAL  OF  ORIGINATOR 

OR  HIGHER  GOVERNMENT  AUTHORITY 

(e)  FOREIGN  GOVERNMENT  INFORMATION. 

Where  appropriate,  this  marking  on  U.S.  documents  ensures 
that  such  Information  is  not  declassified  prematurely  or  made 
accessible  to  nationals  of  a  third  country  without  the  consent 
of  the  originator.  Importing  a  portion  that  contains  such 
Information  into  a  "file"  that  did  not,  poses  for  a  computer 
system  at  least  the  two  problems  emphasized  by  the  Italics: 
correcting  the  declassification  date  (see  below)  and  correcting 
the  dissemination  controls. 

The  notation  for  COMSEC  material  Is  contained  in  DoD 
4220.22-S-l,  a  supplement  to  tlu:  ISM.  The  current 
requirements  for  COMSEC  material  include: 

a.  Keying  material  requires  the  caveat  CRYPTO. 

b.  Otherwise,  the  Notation:  COMSEC  Material — 
Access  by  Contractor  Personnel  Restricted  to 
U.S.  Citizens  Holding  Final  Government 
Clearance. 

CRYPTO  Is  a  label;  It  modifies  a  classification.  COMSEC 
is  a  Notation;  thus  there  is  no  Secret/COMSEC,  for  example. 
Yet  in  an  AIS,  such  a  label  may  be  needed.  For  clearances, 
COMSEC  is  a  label  (ELA  1).  A  contractor  employee  must 
have  a  Secret/COMSEC  clearance  (Secret  clearance  with 
COMSEC  access  authorization)  to  access  Secret  documents 
containing  COMSEC  information.  A  government  employee 
currently  would  need  only  a  Secret  clearance  and  a  need-to- 
know,  (Will  computer  systems  know  what  kind  of  employee 
each  of  us  is?)  COMSEC  access  also  requires  U.S.  citizenship 
and  a  final  clearance;  no  Interim  clearances,  except  an  interim 
Top  Secret,  can  have  access  to  S-  or  C-COMSEC.  COMSEC 
access  authorization  Includes  access  to  CRYPTO;  there  is  no 
longer  a  CRYPTO  label  for  modifying  clearance  labels  (ELA 
1  again). 

A  Notation  required  when  information  is  believed  to  be,  or 
should  be,  or  it  Is  believed  it  should  be  classified,  is: 

CLASSIFICATION  DETERMINATION  PENDING. 
PROTECT  AS  THOUGH  CLASSIFIED 
[appropriate  classification  label]. 


22.  DoD  Industrial  Security  Manual  for  Safeguarding  Classified 
Information,  DoD  5220.22-M,  September  1087,  paragraph  ll.b.(8) 
ADDITIONAL  MARKINGS.  The  Notations  themselves  are  verbatim, 
the  rest  paraphrased  from  the  ISM. 
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Once  notated,  the  document  must  he  protected  at  the 
designated  clnasiiieation  level,  hut  it  does  not  have  to  have 
any  other  labels,  although  it  could  be  marked  with 
appropriate  private  or  proprietary  labels.  Any  apparent 
parallel  between  a  pending  classification  and  an  interim 
clearance  is  purely  illusory. 

A  Notation  required  on  some  documents  (e.g.,  COMSEC) 

is:  Not  releasable  to  the  Defense  Technical 
Information  Center  per  DoD  Instruction  3200.12. 

(Will  computer  systems  art  on  the  basis  or  such  Notations?) 

2.3.3  Authority  Statements.  Classified  documents 
must  be  marked  with  a  statement  that  specillcs  what 
authority  classified  I  hr  documents.  Usually  this  authority 
statement  mnl  I  he  declassification  slatmont  are  combined  into 
one  statement,  but  here  wc  shall  treat  them  separately. 

2. 3.3.1  Classification  Authorities.  Various 
components  of  the  government  are  designated  classification 
authorities,  some  by  law  (e.g„  DOE  under  the  Atomic  Energy 
Act)  and  some  by  Executive  Order."'5  There  are  Original 
Ohissilication  Authorities  and  Derivative  Classification 
(Authorities).  The  latter  is  (are)  required  to  respect  original 
cinssilirulion  decisions  and  to  carry  forward  any  assigned, 
authorized  markings. 

Anyone  who  wants  to  know  how  many  original 
elnssilicatlon  authorities  there  lire  can  read  (  lie  Federal 
Register  and  then  try  In  determine  how  many  other  ollieials 
have  hern  delegated  the  authority,  Or  they  ran  ask  the 
Information  Oversight  Olliee  in  (iencrnl  Services 
Administration  ((ISA):  In  KYS  I.  the  number  was  O.DIK).'"'1 

"Classified  by"  line.  Original  classification  authorities 
are  responsible  for  developing  ehissillenfion  guidelines  for  the 
derivative  classifiers,  who  actually  proiluee  most  of  the 
classilied  information  FYNd:  •l‘r  original.  Ild'-'v  derivative. 
These  guidelines  should  speeify  the  classification  authority 
slaleimmt  to  he  used  on  documents  created  under  its 
authority,  For  contractors  the  statcinenl  should  lie  provided 
via  the  Contract  Security  (  ‘his-ilicalion  Specification  (1)1) 

Form  2>l).  Each  classified  doeumeiil.  (regardless  of  inedimu) 
is  required  to  have  a  marking:  Classified  by 
<something>,  where  something  eo.ihl  lie  the  name  of  an 
agency ,  I  he  name  of  a  elassilientiou  guide,  multiple  sources 
i.e.,  too  many  to  list  (but  a  record  must  be  kept 
somewhere  a  potential  problem  for  computer  systems, 
especially  distributed  ones)  a  Dl)  25-1  for  Contract  < II) > , 
dated  < .lei !•> ,  or,  in  the  ease  or  message  Irniilr,  nothing. 
Messages  do  not  have  to  have  a  Classified  by'  line;  the 
sender,  by  defmilt,  is  considered  to  he  the  classilieation 
authority  for  the  message. 

2.3. 3. 2  Ownership.  Each  classilied  document  is 
required  to  lie  marked  w  ith  the  name  and  address  of  the 
originating  agency  or  facility  mnl  the  pur|xwr  (e.g.,  Contract 
numher)  for  which  it  was  generated.  Ideally,  especially  in 
contractors,  the  document  should  indicate  both  the  preparer 
and  whom  it  was  prepared  for, 

2.3.3. 3  Control  Channels.  When  applicable, 
elassilientiou  authorities  may  designate  certain  control 

2,i.  I'Arrnt ivi  Order  I 2:1", (i  pee  id,-.-  for  Origiu.-il  Clawilir.'tUult 

Authorities  I ’  ■  ■Milrnt ,  Agein  g  I  leads  and  ollieijiLs  designated  ),y  l)je 
ii'sidenl  in  the  I’ rdeml  Ifegisi er.  Olljnnls  delegated  this  iiutliuriiy 

pursuant  to  Seeiiim  1.2(d)  of  the  order,  and  I'.xo'pieUm]  rases  and 

Derivslivc  (.'lassiliratioa 

2-1.  "Annual  Hrpurl  U>  the  President  I'Yl'ISI".  Ii.rormation  Smirity 

Oversight  Ollirp,  OSA,  April  211,  I  Os;, 


chmmels  for  the  distribution  of  their  information.  When 
deemed  appropriate,  documents  in  these  channels  may  be 
required  to  be  labeled  with  a  statement  specifying  the  channel 
required,  such  ns  Handle  via  XV  Z  Control  Channels 
Only.  Control  channels  can  be  implicit:  some  COMSEC 
material  is  controlled  through  the  COMSEC  Material  Control 
System,  hut  this  is  usually  not  explicitly  labeled  as  a 
requirement  on  the  material.  (It  may  need  to  be  explicitly 
labeled  ill  n  computer  system.) 

2.3. 3. 4  Accreditation  Authorities.  Accreditation 
authorities  should  not  lie  confused  with  classification 
authorities.  Classilieation  authorities  determine  what  is 
classified:  accreditation  authorities  (accreditors)  determine 
whether  a  particular  system  can  process  classified  information 
and  at  what  level.  Once  a  system  is  accredited,  the 
accreditor  is  responsible  for  ensuring  that  any  classified 
information  processed  is  appropriately  protected  and  for 
issuing  tlie  appropriate  security  rules  Ibr  operating  the  system. 
A  system  can  be  accredited  by  more  than  one  authority. 

Some  accreditors  may  lie  responsible  for  accrediting  nit 
systems  that  process  a  particular  category  of  information; 
such  accreditors  may  also  be  the  original  classification 
authority  for  the  information."  ' 

2. 3.3.5  Declassification  Statements.  All  classilied 
material  should  be  marked  with  downgrading  and 
declassification  instructions,  ns  appropriate. 

Downgrade  to  <  level  >  on  <date  or  event  >. 

Declassify  on  <date  or  event  >. 

Abbreviations  include:  l)Nti/S/<dato  or  evcnt>  and 
DEG'I,  <datc  or  cvcnl>. 

If  there  is  no  date  or  event,  the  notation  "Originating 
Agency's  Determination  Required"  or  OADR  should  lie  used. 
Importing  from  one  "file"  into  another  limy  pose  problems  for 
a  computer  system  if  the  declassification  statements  diller. 

For  documents  derived  from  or  based  on  multiple  sources,  the 
new  documents  musL  lie  marked  with  the  most  restrictive 
determination. 

When  material  is  downgraded  or  declassified,  I  lie 
classification  labels  mid  other  markings  will  lie  changed  as 
appropriate.  Material  that  has  been  declassified  must  still  lie 
provided  some  degree  of  protect  ion,  Declassification  does  not 
mean  releasable  to  the  public.  Public  release  is  a  separate 
determination. 

Another  marking  required  mi  classified  documents  is  the 
Date  of  Origination.  This  date  obviously  forms  a  base  line  for 
any  downgrading  or  declassification. 

3,  Interdependencies  of  Security  Label  Components 

Relations  among  security  label  ^profile)  components  (figure 
•I)  can  In'  implicit,  or  explicit.  Implicit:  Change  in  one  item's 
label  can  cause  a  change  in  another  item  administratively  but 
without  a  change  in  label.  Explicit:  Change  in  one  item  will 
cause  a  label  for  another  item  to  change  also.  Implicit 
relations  can  lie  handled  easily  enough  by  manual  operations. 
For  electronic  operations,  however,  implicit  relations  may 
Imve  to  lie  changed  to  explicit  ones  Imt  not  necessarily  in  all 
eases. 


20.  I  oiiiiplfs  uf  nrrmliiors  iiirludr  lln-  four  listed  in  tin-  II’  lte»iml 
Security  Option  (iMIl.-S'll)  1777).  Accreditors  lire  usually  owners  of 
ru ntrol  eliannels- 
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Figure  4.  Which  Security  Label  Components  Affect 
Which? 


For  example,  a  Warning  Notice  of  kestririeil  Data  implies 
(1)  that  the  Atomic  Energy  Act  is  Included  in  the 
Classification  Authority,  (2)  tlmt-  DOH  is  included  in 
Ownership,  and  (3)that  the  hierarchical  level  (Classification) 
may  also  he  all'ected.20  Thus,  in  n  eompitter  system, 
importing  an  S-HD  portion  into  a  "llle"  may  idled  all  those 
components  of  the  receiving  file's  security  profile. 

Because  of  the  interdependencies  of  componenls,  either 
Lraiisclnssifyiiig  or' downgrading  a  document  (or  "file")  can 
complicate  its  ultimate  declassification  (lig.  r>-b)  in  the  same 
way  that  amalgamation  often  does  (llg.  i>-a),  immcly,  by 
including  more  owners  and  classification  authorities,  The 
l)OK  could  directly  "declassify"  an  HI)  document  to  Oik),  If, 
however,  DUli  transclassiiies  the  document  ("file")  lo  h’HI)  or 
CNWDI,  then  "derlassiliealion"  to  OIH)  may  require  the 
approval  of  both  the  |)OI:!  and  Dol),  where  (if)  h'HI)  or 
CNWDI.  implies  that  Dol)  is  included  in  ownership  and 
classification  authority,27  From  a  Dol)  viewpoint, 
"declassifying"  a  CNWDI  document  may  l>c  more  complicated 
simply  because  the  D OK  is  the  originating  agency,  as 
indicated  by  the  required  Restricted  Data  noialioii,  and 
"OAOK"  applies  even  if  it  does  not  appear  explicitly  on  the 
document. 
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Figure  5.  Expanding  Ownership  Complicates 
Re-Classification. 


20.  A  runuiion  iiiiscuiKcpLion  oocddc  U.r  DOK  is  Unit  Itl)  or  (NWl)l 
Implies  at  least  Secret.  Tliere  is  plenl’i  i,f  O-lll)  .'ill' I  S-lll),  and 
relatively  little  TS-ltl)  CNWDI  run  also  be  ('.  S,  nr  TS.  In  ailililioa. 
CNWDI  limy  be  categorized  as  Sigmn  1  (theruioniirlear).  Sigma  2 
(fission),  etc. 

27.  tor  brevity,  we  use  tlie  portion  labels  for  the  ■luniniriil  labels. 


4.  Further  Implications  for  Computer  Systems 

4.1  Messages.  In  messages,  the  title  page  and  portion 
markings  are  usually  considered  text:  the  author  is  required 
to  include  them  in  the  tody  of  the  message.  The  page 
markings  are  also  in  the  text,  top  and  bottom,  hut  the  highest 
page  marking  must  also  be  attached  to  the  container, 
envelope,  packet,  etc.  that  transmits  the  message.  In  otliei 
words,  major  portions  of  what  may  eventually  need  U>  be  part 
of  a  (trusted)  security  profile  and  therefore  may  need  to 
reside  in  (and  be  controlled  by)  the  TCB,  resides,  with  current 
implementations,  in  the  contents  of  the  message,  Ideally, 
computer  security  and  specifically  the  avoidance  of 
unauthorized  disclosure  should  not.  depend  on  automated 
message  contents,  i.c.,  data  integrity. 

4.2  Distributed  Systems.  In  a  distributed  computer 
system,  users  may  be  able  to  access  remote  resources. 

Labeling  requirements  will  vary  according  to  the  granularity 
of  transfer.  We  illustrate  the  problem  in  figure  0.  Importing 
a  portion  of  a  "file"  into  another  (on  a  different  host  or  file 
server)  may  result  in  the  loss  of  that  security-related 
information  and  control  provided  by  the  title  markings 
associated  with  the  "sending  file".  While  the  same  problem 
could  occur  in  a  monolithic  computer  system,  it.  seems  almost 
inevitable  in  a  distributed  system,  and  its  solution  more 
remote  (no  pun  intended). 


Figure  6,  Loss  of  Security  Label  Components  in  a 
Distributed  System. 

We  illustrate  the  problem  more  concretely  in  figure  7. 

The  context-  could  be  monolithic  or  distributed.  The  "file" 
resulting  from  the  import  may  have  its  Classification 
Authority  expanded  to  the  union  of  the  two  separate 
authorities.  The  owner  might,  remain  the  same  if  no 
proprietary  information,  special  requirements,  or 
interdependencies  (as  in  our  I)OIi/Dol)  example)  apply.  The 
resulting  Control  Channel  will  be  per  agreement  among  all 
channels  involved.  The  resulting  Declassification  Statement 
will  be  the  more  restrictive.  (We  assume  OADR  is  more 
restrictive  than  2  years.)  Finally,  any  Notation  applicable  to 
tlic  imported  portion  must,  lie  included  in  the  result. 


7.64 


Figure  7.  Problem  even  in  a  Monolithic  Computer 
System. 


5.  Conclusions 

We  hope  it  is  abundantly  clear  that  security  labels  an* 
nut  simple.  They  provide  more  needed  security-relevant 
information  than  sensitivity  alone.  Kveii  sensitivity  is 
nontrivial.  Neither  ilo  classifications  ami  clearances 
necessarily  map  directly,  one  to  the  other.  The  implications 
for  secure  computer  systems  may  he  profound,  especially  for 
those  systems  that  will  seriously  and  dislrihulivrly  attempt  to 
replace,  us  far  as  possible,  manual  operations  on  hardcopy. 

(X  course,  if  one  never  generates  any  documents  (hi 
whatever  medium)  of  any  significant  longevity;  if  all  one’s 
actions  arc  "quick  and  dirty"  and  simple  (and  on  a  monolithic 
system),  then  getting  tile  Declassification  Statement  wrong  on 
u  sensitive  document  may  never  actually  result  in  the 
document’s  unauthorized  disclosure.  Ihnler  tin  .e  limiting 
conditions,  perhaps  some  of  our  other  examples  go  away  as 
well.  But.  "quick  and  dirty"  contradicts  security;  and  simple, 
monolithic  systems  arc  the  past,  not  the  future. 

We  hope  to  discuss  in  detail,  in  it  future  paper,  our 
thoughts  on  possible  solutions  to  some  of  the  problems 
presented  here.  At  present,  however,  in  our  judgement,  the 
community  is  not  "ready 1  for  genera!  solutions.  There  is  not 
just  a  lark  of  consensus  on  what,  the  problems  are  or  on  what 
some  reasonable  candidates  for  solutions  might  he.  There  is 
not  yet  even  much  perception  that  a  general  solution  is 
needed.  Bach  agency  understandably  tends  to  view  its  own 
classification  and  security  procedures  as  relatively  sane  and 
simple.  (Familiarity  with  procedures  encourages  tins  view 
whether  it  is  well-founded  or  not.)  As  one  person  at  IH)K 
stated,  'The  complexity  of  the  issue  is  in  DOF’s  interactions 
with  the  DoD  and  other  foreign  governments,  not  within  the 
department."  Here  "other"  is  a  redundant  synonym  for 
"foreign",  hut  the  unintended  suggestion  that  the  DoD  is  a 
foreign  government  underscores  the  person’s  i- *i ut  that  the 
dillieulty  lies  at  the  boundary.  Currently  the  DOK  exchanges 
tiles  with  DNA,  a  DoD  agency.  While  the  DOK  admits  that 
"file  handling  is  messy  and  the  [file]  headers  are  IIUt.K",  they 


have  confidence  in  the  security  of  the  exchange  and  remain 
comfortable  with  a  distinction  between  sharing  liles  and 
sharing  documents.  Of  course,  the  DOK  is  just  one  example 
that  interfaces  with  the  DoD.  As  automated,  inter-agency 
traffic  increases  (both  the  traffic  and  number  of  sharing 
agencies),  each  agency  may  understandably  become  more 
concerned  about  what  agencies  Lite  agencies  they  share  with 
share  with.  A  general,  standardized  security  mechanism  such 
as  security  projiles  may  then  he  demanded  by  such  agencies 
or  mandated  from  above;  and  the  distinction  between  sharing 
documents  and  sharing  files  may  no  longer  be  viable. 

At  the  top  level  and  for  monolithic  computer  systems,  one 
solution  may  be  staled  simply  enough:  Identify  nil  gaps 
between  security  procedures  for  clearances  and  classified 
hardcopy,  on  the  one  hand,  and  current  AlS  practice  on  the 
other;  then  close  those  gaps  by  including  the  required 
information  in  a  genuine  security  label  mechanism. 

Obviously,  this  is  easier  said  tnan  done. 

Simply  what  constitutes  a  complete  list  of  gaps  is  not,  in 
general,  known  or  agreed  upon.  The  "list"  given  here  can  be 
expanded.  Thus,  as  a  parting  shot,  consider  the  retention 
problem.  Classified  hardcopy  may  lie  associated  with  a 
specific  contract,  identified,  say,  ns  number  N.  Said  contract 
lias  an  estimated  expiration  (completion)  date,  KKI)  [cj.  1)1) 
form  ‘JfM).  Depending  on  contractual  relations  and  whether 
data  is  to  go  from  one  company  lo  another,  permission  tuny 
or  may  not  be  needed  to  export  data  from  the  document  to  a 
document  associated  with  a  dillcreut  contract.  Customarily, 
at  the  KKI),  either  the  KKI)  is  extended  or  the  document 
must  lie  destroyed  within  a  specified  lime,  typically  DO  days. 
Destruction  of  hard  or  soft  copy  under  a  dilforenl  contract 
(including  data  imports)  may  lie  someone  vise's  problem,  hut 
destruction  of  eonlraot-N  identified  copy  must  include  all 
copies,  including  automatically  gcucraicd  backups.  (We  say 
nothing  hero  alxnit  the  problem  of  (magnetic)  ivuinuencc.) 

The  eonlrncl  number  and  the  dale  of  the  most  recent 
applicable  1)1)  form  !W-I  may  lie  indicated  in  the  "Classified 
by"  marking  of  a  hardcopy  document,  hut  the  KKI)  itself  is 
not  on  the  document.  Here  again  automation  may  require  the 
security  prcjile  of  the  soft-ropy  to  contain  even  more  than  the 
full  set  of  markings  on  the  corresponding  hardcopy. 

While  solutions  to  the  problems  broached  here  may  lie 
tailored  to  a  specific  application  on  a  monolithic  computer 
system,  such  an  ad  hac  approach  seems  inellieieiil  from  a 
software  development  view.  Neither  does  sueli  an  approach 
lend  itself  to  verification  of  either  tie'  formal  or  less  formal 
kind. 

For  distributed  systems,  tve  expect  the  same  problems  to 
he  harder.  Communications  protocol  standards  are  only  now 
being  agreed  iqion  which  leave  no  room  for  all  the  additional 
data  that  would  be  needed  (o  hold  a  I'nll-lledged  security 

label. 
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MANAGING  THE  ACCREDITATION  PROCESS: 
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INTRODUCTION 

Accreditation:  A  oolmy  decision  by  the  responsible 
Designated  Approving  Authority  (DAA)  resulting  in  a 
formal  declaration  that  appropriate  security 
counter1'  'asures  have  been  property  implemented  for 
the  computer  (AL)P)  system  or  network. 

The  process  involved  in  preparing  for  the  at.  ’■editation 
of  a  computer  system  or  facility  is,  in  many  ways,  akin  to 
doing  your  federal  income  taxes  --  it  is  u  labor  intensive 
process,  requires  a  mass  o(  supporting  documentation,  and  is 
almost  certaat  to  frustrate  the  most  eventempured 
participant.  In  fact,  it  seems  that  the  less  organized  you  are. 
iho  mom  fm  '-rating  an  experience  you  will  have  --  in  both 
taxes  and  accreditation! 

The  primary  intent  of  this  paper  is  to  help  others  avoid 
unnecessary  fnis‘ ration  by  sharing  some  of  the  lessons  that 
vir  In vo  c.uileciively  learned  --  some  the  uard  way  -- 
o.n'og'i  direct  pa:  m.pation  in  a  variety  of  different 
arcrucLtation  , expei  iiinxes  W'e  share  a  common  concern 

.mud  through  our  i'xiit/nirent  in  computer  security  us  civil 
servants,  mditai  '  |s.i<.on>tei,  and  consultants  svho  have  helped 
accier.'t  systems  -r  the  Depot'  mint  of  Defense,  selected 
S.  exilian  agen..  i  s.  and  the  Department  ot  Energy.  Based 
c.n  these  experiences,  we  believe  that  the  success  of  a 
computer  system  accreditation  (or  certification)  is.  in  very 
large  part.  JepenuBiU  upon  the  v.vy  it  is  managed  from  the 
start. 

Be-  •.  sii  the  many  different  agencies  and  departments 
we  have  eisne.  served  in  or  supported,  it  is  hoped  that  there 
is  broad  applicability  to  thr  the  lessons  presented  here.  They 
should  be  useful  '.r  anyone  inside  or  outside  the  government 
who  finch  hi.fi-  t .  herself  involved  in  planning,  managing,  or 
par  I  impaling  in  any  portion  of  the  .iccied.lation  process.  The 
iiestr.:  >c  save  money  and  reduce  waste  is  also  another  reason 
for  this  paper:  it  is  doped  that  dollar  depleting 
wheel-spinning  can  be  avoided  by  applying  some  of  the 
lessons  offered.  Finally,  while  accredit. it. on  is  on  experience 
Hut  the  defense  comm  unity  has  lived  */ith  for  a  long  time, 
'be  c.vilian  agencies  have  not,  for  tb?  most  part,  had  to 
comply  with  its  many  requirements.  Risk  assessment,  annual 
loss  expectancy,  contingency  planning,  security  tests  and 
evaluations,  etc.,  may  l.n  foreign  *o  many  of  the  federal 
government  's  unclassified  yet,  critic. ,1  computer  operations. 

But  the  climate  appears  to  be  changing  and  concern  for 
computer  security  in  ’.ids  sector  is  slowly  increasing.  It  is 
therefore  also  our  intern  to  share  our  .'patience  with  those 
in  that  comr'imiV;  wh.i  are  gearing  up  for  an  accreditation  or 
certification.  The  paper  is  organized  according  to  the  key 
phases  involved  in  the  accreditation  process;  initia1 
preplanning,  risk  assessment,  security  test  and  evaluation, 
and  the  final  phase  of  preparing  and  presenting  the  formal 
i-tcreditat'on  pacings.  The  remainder  of  this  paper 
nighli^'s  many  of  ho  me  t  frequently  cited  ptublnm  areus 
’.hat  i  ,i  per  each  ;r  these  phases,  and  offers  suggested 
approaches  for  avoidinf  ‘htse  glitches  m  future  accreditation 
i:'l'orts. 


THE  PLANNING  PHASE: 

LAYING  THE  FOUNDATION  FOR  SL'GCESS 

Solid,  up-front  planning  establishes  the  foundation  for  a 
smooth  and  successful  accreditation  experience.  While  this 
may  seem  intuitively  obvious,  there  are  enough  "war-stories'' 
around  of  accreditation  snags  and  mix-ups  to  indicate  that 
the  rudiments  of  this  phaso  are  frequently  only  given  lip 
service  or  are  altogether  igno"ed. 

(1 )  Define  the  Roles  and  Responsibilities  of  All 

Participants 

Accreditation  requires  the  participation  of  numerous 
people.  Those  most  intensively  involved  aru  the 
accreditation  team  leader  and  team  members.  The  assembly 
of  a  multidisriplinai  •  accreditation  team  is  essential  if  all 
facets  of  accreditation  are  to  be  addressed  with  a  high  level 
of  confidence.  The  team  should,  at  minimum,  have  expertise 
in  the  following  areas  of  security:  computer,  physical  and 
environmental,  communications,  and  emanations  (TEMPEST). 
The  team  leader  should  be  definitive  about  who  will  be 
responsible  for  each  of  these  ureas  throughout  Thu  process. 

But  aside  from  the  accreditation  team,  there  are  u 
number  of  other  key  people  who  must  be  identified  early  cm 
in  the  process  ami  with  whom  accreditation  requirements 
must  be  precoordir-oted.  Senior  decision  makeis  responsible 
foi  approving  budget  expenditures  and  labor  assignments 
should  be  b.iefed  at  the  start  with  regard  to  resource 
requirements,  milestones,  and  any  special  needs  mat  the 
team  anticipates.  If  that  individual  or  group  of  individuals  is 
not  fully  conversant  with  accreditation  specifically  and 
security  geiicrell.,  a  brief  overview  of  the  process  is  also 
worthwhile  This  is  particularly  true  if  accreditation 
resource  requirements  are  larger  than  the  allocated  security 
budget  (which  in  most  cases  is  true  since  security  is  rarely  a 
dollar-rich  line  item  in  the  operating  budget). 

Other  key  individuals  with  whom  early  contact  must  be 
established  include  the: 

Computer  faeplity  manager  and  principal  system 
operators  (to  coordinate  scheduling  of  the  risk 
assessment  and  ST&E  w;th  the  objective  of 
minimizing  system  down  times,  as  well  as  to 
collet;1,  all  syslem/ facility  background  information 
relevant  to  the  accreditation) 

System  security  officer  (SSO).  if  one  has  been 
selected  (to  participate  on  the  team  or  to  assist 
the  team  in  collecting  all  necessary  data  during  the 
jrvey,  risk  assessment,  and  ST&E  phases) 

Agency  or  headquarters  security  office  (principally 
for  coordination  on  physical  and  environmental 
security  concerns  and  threats) 

Agency  or  headquarters  engineering  office  (to 
address  facility-related  design,  construction, 
environmental,  and  electrical  issues  and/or 
quest  ons  throughout  the  process) 
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local  law  enforcement  agencies  or  represent  a  lives 
(in  (he  event  (hat  additional  threat  data  is 
necessary)  , 

Nearest  Military  Intelligence  (MI)  Group  (for 
up-to-date  TF.MPEST  throat  and  espionage  data 
and  survey/test  assistance). 

Since  formal  TKMPKST  surveys  are  generally  scheduled  hased 
on  the  importance  of  the  computer  facility's  operations,  this 
last  point  is  particularly  crucial  if  accreditation  must  be 
achieved  within  a  certain  period  of  time.  One  team  leader 
briefed  his  supervisor  that  accreditation  could  be 
accomplished  in  4  months,  oniy  to  discover  that  there  was  a 
significant  wailing  period  for  the  required  survey! 
(Fortunately  there  was  a  happy  ending  to  this  story  he  was 
able  to  piggyback  his  survey  with  one  that  had  been  scheduled 
for  a  nearby  facility  with  a  higher  priority  operation.) 

(2)  Precoordinaie  at  id  P  res  c  lie  d  u  l_c_  As_M  uc  hA  s  Possible 

Based  on  the  preceding  discussion  of  roles  and 
responsibilities,  it  is  clear  why  precoordinatum  and 
prescheduling  are  worthwhile.  Front  the  standpoint  of  the 
accreditation  team,  it  also  provides  for  well-coordinated 
interfaces  with  the  nuinennis  offices  and  personnel  with 
whom  they  will  have  stunt  net.  No  one  likes  to  answer  the 
same  questions  repeated  by  different  members  of  the  team, 
nor  do  thuy  appreciate  redundant  requests  for  data  which 
could  have  been  provided  during  one.  single  session,  in  other 
words,  it  is  critical  to  pre  plan  all  survey  questions  to  tie 
asked  by  each  team  member  in  order  to  nneum/e  repetition, 
tumeeded  back/t  racking.  and  successive,  costly  situ  visits. 

I  he  development  of  a  comprehensive  schedule  and  .1 
compamon  accreditation  "diary''  is  also  integral  tu  a 
well  planned  effort.  They  serve  to  provide  a  clem- 
understanding  of  the  accreditation  timetable  along  with  tint 
agreed  upon  responsibilities  of  each  person  involved.  The 
diary  should  include  dales  when  preeourdiii.ition  meet  mgs  or 
contacts  took  place,  the  namefsl  of  the  individually)  with 
whom  the  in  r;mgi-mfnt(.s|  were  established  and  the  da(e|s)  of 
the  planned  meetings,  the  survey,  risk  assessment.  STM-1, 
etc.  Advance  scheduling  of  critical  Hirelings  or  events  is 
especially  uiipoitant.  particularly  when  they  involve  senior 
decision- makers  or  entail  a  sigmlicanl  occurrence  such  as  a 
system  shutdown  l-nr  the  ST.ST1.  And  finally,  a  word  to  the 
wise:  all  meetings  should  be  con  I'll  toed  a  day  or  two  in 
advance  to  ensure  all  key  attendees  will  lie  available  as 
planned.  One  team  member  made  .1  very  long  trip  only  to 
Imd  that  a  key  point  of  contact  was  on  leave  for  the  week, 
in  advance  phone  call  ought  have  saved  the  day. 

(!)  Make  l  sent  fhe  Fruits  of  Others  I.  uUas 

In  many  instances,  a  computer  facility  fucu  g 
accreditation  is  located  m  the  same  budding  or  on  the  satire 
base  or  cen'er  where  an  accreditation  has  recently  taken 
place.  It  is  peifettly  acceptable  to  coordinate  with  the 
participants  of  the  previous  accreditation  activity  to  solicit 
daci  and  information  that  is  pertinent  to  the  ongoing  effort. 
In  many  cases  e  threat  data  that  pertained  to  the 
icuetliled  facility  are  apt.’’  able  to  the  othci.  am!  can  lie 
massaged  In  lit  current  I'.crd'ialimi  needs  It  is  .uk  is.dilc 
10  preioniidmale  ibis  step  vvi’h  the  DAA  s  representative  to 
ensure  that  hrestie  does  not  olni’i  I  to  'Ins  tone  saving 
ippillilCil. 

In  lies  same  vein,  it  is  important  to  acquire  as  much 
available  data  and  history  ibov.l  the  computer 
t.ieiiilv'svsleiit  as  possible.  Of  nilerest  w-ould  be  anv  rei.oiils 
ml  ilia  101  iiml.'ir  minor  system  down  times  ami  their  causey 
i  UC  failure,  electrical  outages,  weather  related  problems, 
etc  l:  security  track  records  and  incident  reports,  and  all 
system  mission  and  organization- related  data.  This  type  ol 


information,  assembled  as  part  of  the  daily  operational 
regimen  of  a  facility,  can  be  invaluable  to  the  accreditation 
team. 

(-))  Collect.  Read,  and  Analyze  All  Applicable 

Inst  ructions.  Regulations,  and  Standards  in 

Their  Entirety  Early  On 

While  this  statement  also  seems  so  patently  obvious  that 
it  should  not  merit  discussion,  war-stories  dictate  otherwise. 
To  avoid  sutprises.  it  is  prudent  to  collect  and  thoroughly 
read  all  documented  requirements  that  pertain  to  the 
accreditation  of  the  given  system  before  doing  anything  else, 
This  early  familiarization  period  allows  the  'earn  manager 
and  members  to  identify  whether  method  'logins  and 
approaches  set  forth  in  the  documentation  fit  the  reality  of 
their  particular  accreditation  situation.  Additionally,  it 
allows  them  to  pinpoint  any  areas  where  guidance  is 
ambiguous  or  non-oxistant.  This  will  also  allow  the  team  to 
strategize  in  advance  regarding  how  they  will  address  any 
special  accreditation  issues  that  are  not  specifically  covered 
in  their  respective  agency's  accreditation  guidance.  Finally, 
in  those  casus  involving  multiple  agencies,  agency-specific 
accreditation  standards  must  be  integrated  into  a 
memorandum  of  understanding  that  sets  forth  the  agreed 
upon  accreditation  needs  of  the  multi-usur  system. 

(5)  Use  the  Tools  of  the  Trade"  to  Maximize 

fttjjci  unity 

The  accreditation  team  can  vastly  simplify  its  task  if  it 
plans  in  and  precoordnmtos  the  use  of  selected  accreditation 
"tools."  For  instance,  if  permissible  during  the  site  survey, 
the  use  of  a  hand-held  dictaphone  for  note  taking  greatly 
speeds  up  an  otherwise  tedious  process.  The  use  of  a  :i&mm 
camera  has  also  proven  to  be  useful  111  cerium  situations, 
Photos  are  not  intended  for  publication  in  the  I  in.il  package 
as  a  rule,  hut  rather  are  used  by  tiu’iu  membeis  to  log  their 
memories  when  developing  survey  and  assessment  results.  It 
can  also  be  invaluable  in  tracking  die  progress  of  maiur 
systum  changes  over  lime  that  have  un  impact  mi  security, 
and  provides  a  head  start  on  tile  system's  accreditation  or 
certification. 

fhe  team  should  also  avail  itself  of  the  latest  Evaluated 
Products  last  I  FPL)  which  invei’tones  all  computer  securilv 
products  approved  tor  use  by  the  IX )l )  Coinpuuir  Security 
Center,  us  well  as  the  latest  Uatapro  reports  which,  list  all 
available  computer  products  and  their  capabilities,  to  include 
secunly  features  for  given  releases  of  software. 

Finally,  the  team  may  find  that  1nstn1etmn.il  videos, 
similar  to  one  that  we  recently  produced  for  the  N.ivv.  can 
simplify  many  facets  of  the  accreditation  process,  help 
explain  key  roles  and  responsibilities  to  prospective  team 
members  and  other  participants,  and  provide  a  cost  etfcctive 
security  training  tool  for  use  by  the  SS()  throughout  the 
lilecycle  of  the  system. 

rilF.  KISk  ASSKSSMKVr  PH  ASK:  STAMM;  IN  II  IK 
UKIVFKS SKA  1 

Perhaps  the  most  frequently  menlmneil  liability  during 
this  phase  of  the  accreditation  process  is  the  lendem  y  to  let 
the  documentation  drive  you  rather  than  the  other  way 
around.  The  applicable  regulations  and  instruct. oils  provide 
policy  and  guidance  on  bow  best  to  determine  anil  measure  a 
system  s  vulnerability  to  specific  risks.  Hut  the 
accreditation  team  is  responsible  for  actively  managing  the 
overall  process,  and  is  affoided  a  curtain  degree  of  latitude 
in  meeting  this  responsibility. 

Wiule  the  degree  of  latitude  in  selecting  a  risk 
assessment  methodology  may  vary  depending  upon  whether 
the  system  will  process  classified  information,  the  team  can 
generally: 
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Select  the  best  risk  asse.ssinenl  methodology  for 
the  given  systiiin  (e.g,,  qiuditntivn  versus 
quantitative) 

Determine  whether  an  automated  risk  assessment 
package  makes  sense  for  the  accreditation 
siumiion  at  hand  and.  if  so,  make  an  appropriate 
selection 

Select  the  most  suitable  format  and  "packaging" 
strategy  for  all  documentation  prepared  as  part  of 
tins  and  subsequent  phases 

Consider  any  planned  system  enhancements  m 
selecting  tile  methodology  in  order  to  facilitate 
future  risk  assessments. 

Finally,  if  the  team  is  considuring  use  of  anything 
exotic',  it  is  strongly  advisable  to  touch  hast1  with  thu 
DAA's  representative  to  determine  whether  the  approach 
under  consideration  is  acceptable  --  before  digging  in  too 
deeply.  In  one  instance  a  system  developer  toyed  with 
designing  his  own  odd  on  security  software  package, 
assuming  that  this  was  an  accept  able  approach  to  managing 
the  system's  risks.  Tito  DA  A  had  other  ideas  on  this  sobiect. 
however,  and  use  of  onlv  a  lew  software  packages  with  solid 
socuiity  peiionnance  recotds  was  considered  acceptable  for 
this  puiticulur  classified  system  configuiution.  Luckily  the 
question  v.  us  asked  fust. 

THKSKCIRII  Y  I'lkS'l  AMD  KVAl.l'A'l  ION  fST*  F.)  PHASE. 
R.AMMM'i  TO  ADDRESS  Till'.  OMITTKD 
'  AMD  UMMF.NTIUNIIl) 

Once  tlte  risk  assessment  is  completed  and  all 
recommended  cou.ilermeasures  have  presumalily  been 
tmplemimtml.  the  SINK  team  is  re.s|xiiisil)le  for  ensuring  t hat 
the  system  s  secuuty  countermeasures  exist  and  serve  their 
intended  purpose.  The  accreditation  team  manager  can 
provide  a  thread  of  continuity  between  these  two  phases, 
since,  as  a  rule,  survey; usk  assessment  team  members  do  nut 
participate  m  the  STY K  to  ensure  full  objectivity. 

Decause  a  separate  team  is  involved  in  t tin  SIM-', 
proi  ess.  tim  problems  that  are  rrnqiientl\  encountered  during 
Ibis  phase  ue  associated  with  continuity  Specilically.  the 
STAF.  team  must  hope  that  the  risk  assessment  report,  which 
they  will  use  extensivelv  in  preparing  for  theSTML  addresses 
all  system  fietiuom.ies  and  associated  cmintermeasures. 
Frequently,  the  risk  assessment  addresses  only  those 
countermeasures  identified  as  part  ol  the  .ism  -.sment  and 
omits  mention  ot  any  that  were  alrc.idv  in  place  and 
effective.  Urns,  the  STM',  team  sluuld  plan  on  foils 
immersing  itself  in  all  available  iiociiineiil.it ion  not  onlv 
the  risk  assessment,  hut  also  system  mission  statements, 
standard  operating  procedures,  etc.,  to  ensuui  that  ill 
countermeasures  are  tested  and  discussed  in  the  final  SIM. 
report  Tins  is  cnnc.il  sin.  e  the  report  is  used  by  the  DA  Y  to 
make  the  final  accreditation  decision 


The  need  for  ample  precooioinatmn  prior  to  and  during 
the  ST& F,  is  also  critical.  The  necnssily  for  p rescheduling  the 
STM!  itself  has  already  been  emphasized  above.  As  the.  date 
approaches,  the  tost  director  should  coordinate  test  activities 
with  all  involved  site  personnel.  Moreover,  nnv  special 
requirements  for  the  ST&E  should  bn  discussed  in  detail  with 
the  system  manager  (e.g..  color  changes.  system 
shutdown/start-up,  etc.)  This  test  director  should  also 
require  that  each  STS. F.  team  member  prepare  a  schedule 
showing  tile  sequence  of  tlwir  specific  test  activities.  This 
will  cause  team  members  to  critically  review  and  plan  their 
tests,  eliminate  back  tracking,  and  expedite  tin  test. 

Presentation  of  the  ST&K  results  is  the  final  maior 
hurdle  in  the  STNE  phases;  it  can  also  bring  the  process  to  a 
standstill  if  (1)  the  ST'&lv  uncovers  a  deficiency  which  must 
he  corrected  before  the  DAA  will  accredit  the  system,  end 
(2)  m  order  to  correct  the  deficiency,  additional  resources 
are  required.  Since  accreditation  is  frequently  regarded  as 
"that  time-consuming  Irritant  that  senior  decision  maker  s 
learn  to  live  with"  --  few  team  leaders  I'eei  comfortable 
making  a  presentation  that  concludes  with  a  request  for  more 
money.  In  the  filial  analysts,  this  presentation  is  a  sales 
pitch,  not  a  results  briefing  that  the  team  leader  or  his 
supetv isor  must  present.  It  should  be  viewed  as  such  and  thu 
content  of  the  presentation  must  lie  on-  target,  high  level  in 
perspective  (versus  forcing  feuding  a  busy  decision  maker 
endless  tactical  details),  and  as  upbeat  in  tone  as  possible. 
While  tills  suggested  approach  will  not  gunranloe  a 
commitment  of  additional  resources,  it  will  Impefully  make  it 
more  likely. 

tv imc;  ui'  v  kmds  and  utiier  finai.  remarks 

The  iast  majoi  huidle  to  cross  in  tile  accrudi Wilion 
process  is  effectively  organizing  all  the  team's  findings  and 
supporting  documentation  into  olio  document  that  will 
comprise  die  formal  accreditation  package.  A  word  to  tile 
wise  here  the  importance  of  a  well  ntganized  presentation 
and  report  cannot  be  over  stressed  Thu  presentation  should 
include  a  detailed  table  of  contents-  that  serves  as  a 
road  map'  for  the  DAA  m  his/ltei  review  el  lorl.  Again 
this  will  not  ensure  accreditation  oi  the  system,  but  it  will 
certainly  establish  a  good  first  impression  regarding  the 
team  s  overall  professionalism  and  pei  lorinnncc. 

in  die  final  analysis,  a  well  managed  aciredi latum 
effoit  provides  an  excellent  learning  opportunity  lor  all  those 
that  it  involves,  facilitating  a  grinder  appreciation  lor  the 
many  risks  to  which  a  computer  system  is  exposed  and  the 
ways  in  which  such  risks  can  lie  minimized,  however,  when 
the  process  is  unuumaged  <11  ill  managed.  ,t  can  lie  a  cosily 
and  nightmarish  experience  for  all  ennenmed.  hopefully  the 
lessons  set  forth  Imre  will  help  ltiu.se  who  might  lace  such 
involvement  to  turn  the  experience  into  the  positive 
management  challenge  that  it  can  and  should  he. 


(6)1988  .lennle  SU- veils 
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Abstract 

This  paper  addresses  two  multilevel  security  problems 
that  appear  to  require  write-down  of  data.  However,  such 
write-down  would  incur  risks  since  it  makes  visible  to  users 
data  that  is  derived  from  information  for  which  the  users 
are  not  cleared.  The  proposed  approach  essentially  avoids 
write-down  in  both  cases,  thereby  increasing  the  level  of 
assurance  of  the  system.  The  first  case  arises  in  a  multi¬ 
level  rulo-bascd  expert  system,  where  we  need  to  ensure 
that  a  low-lcvc!  user  will  not  bo  given  grossly  inconsis¬ 
tent  or  harmful  advice  due  to  higher  level  rules  and  data 
not  being  available.  The  second  case  arises  from  use  of 
rules  to  assign  classification  labels  to  new  data  entering  a 
multilevel  database  system. 

1  Consistency  for  Multilevel  Rule-Based 
Systems 

Rule-baaed  Expert  Systems  currently  operate  at  a  single  classi¬ 
fication  level.  However,  there  will  be  increasing  need  for  rule- 
based  systems  in  which  the  rules  themselves  may  have  classifi¬ 
cation  labels,  as  well  as  ‘he  data  on  which  these  rules  operate 
Examples  are  discussed  by  Berson  and  Lunt  [2).  Only  rules  at 
or  below  the  user's  clearance  level  would  be  invoked  on  behalf 
of  the  user,  and  only  data  at  or  below  the  user’s  level  could  he 
utilised  by  the  rules. 

An  important  problem  which  arises  for  such  multilevel  rule-based 
systems  is  the  consistency  of  the  results.  By  consistency,  we 
mean  that  these  results  would  not  seriously  conflict  with  require¬ 
ments  of  the  application.  Such  consistency  could  be  achieved, 
but  at  the  expense  of  security,  if  the  results  were  initially  pro¬ 
duced  with  the  system  running  at  system-high  and  then  an  at¬ 
tempt  were  made  to  sanitize  these  high  results.  However,  run¬ 
time  sanitization  generally  would  not  be  acceptable  due  to  the 
complexity  of  such  a  sanitization  process  and  the  need  for  it  to 
handle  a  very  wide  range  of  information.  It  in  not  likely  that 
auch  complex  eanitlzatlon  could  be  sufficiently  trusted. 

We  propose  a  method  which  we  call  spiral  con-iistcncy  enforce - 
mint  to  essentially  avoid  this  write-down  problem.  A  key  aspect 
of  this  method  it  independent  execution  of  two  similar  expert 
system  processes  at  two  different  classification  levels.  The  sepa¬ 
rate  results  are  then  compared  by  a  verification  process  to  ensure 
that  the  recommendations  formed  at  the  user's  level  are  safe  and 
consistent  with  the  technical  requirements  of  the  application. 

For  example,  the  expert  system  should  not  propose  a  mission 
with  advice  to  use  sunglasses  (a  glare  shield)  when  in  fact  the 
more  highly  classified  details  of  the  mission  actually  require  thick 
lead  radiation  shielding.  It  would  be  far  better  for  the  system 


to  simply  not  propose  the  mission  at  all,  than  to  risk  human 
life.  The  verification  process  has  the  responsibility  to  determine 
whether  the  result  computed  at  the  user’s  level  is  valid  or  invalid, 
and  to  produce  a  yes/no  decision  as  to  its  use.  The  primary 
stages  needed  for  this  enforcement  of  consistency  are: 

Spiral  Consistency  Enforcement: 

1.  Primary  Process:  Execute  the  rule-base  of  the  expert 
system  at  the  classification  level  of  the  user,  generating 
what  we  call  the  primary  result  ? ,  Since  this  process  omits 
rules  and  data  that  are  not  dominated  by  the  user’s  level, 
the  primary  result  satisfies  all  security  requirements  (as¬ 
suming  the  original  classification  labels  on  existing  data 
and  rules  were  assigned  properly). 

2.  System  Process:  In  a  separate  process,  execute  the  rule- 
base  at  system-high  or  at  the  highest  level  deemed  nec¬ 
essary  to  ensure  that  the  secondary  result  S  produced  by 
this  step  is  completely  consistent  and  acceptable  from  the 
viewpoint  of  the  application  -  i.e.,  that  critical  application 
requirements  are  satisfied.  Call  the  level  of  this  result  L$. 

3.  Verification  Step:  At  this  higher  level  Lj,  execute  a  ver¬ 
ification  process  V  whose  task  Is  to  determine  whether  the 
primary  result  P  produced  at  the  lower  level  violates  any 
essentia!  constraints  of  the  application  relative  to  the  more 
complete  secondary  result  S .  This  process  V  only  com¬ 
pares  the  two  results  but  makes  no  changes  to  either.  The 
sole  output  of  V  is  a  binary  yes/no  indication  of  whether 
it  1c  acceptable  to  release  the  primary  result  to  the  user. 
For  example,  if  the  primary  result  is  so  far  afield  that  it 
could  endanger  human  life,  then  It  would  not  be  released. 

4.  Release  of  Results:  If  this  verification  falls  (i.e.,  indi¬ 
cates  ‘don’t  release’)  then  either  no  result  Is  produced  by 
the  system  or,  perhaps,  a  cover  ttory  result  is  presented. 
If  the  verification  succeeds,  then  just  the  primary  result 
P  —  which  already  is  at  the  user’s  level  —  is  presented 
to  the  user.  It  is  important  that  these  four  steps  operate 
as  an  atomic  unit,  In  that  no  data  Is  released  except  at 
the  proper  completion  of  this  final  step.  Any  system  Inter¬ 
rupt  or  suspension  of  processing  during  these  steps  must 
be  safeguarded  to  not  release  data  directly  or  Indirectly. 

This  approach  avoids  the  direct  use  of  the  higher  level  rules  in 
creating  the  mission  plan,  thereby  avoiding  a  potentially  serious 
downgrading  problem.  When  primary  results  are  released  to  the 
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user,  we  know  that  they  were  generated  only  from  use  of  the 
lower  level  rules.1 

Thus  this  procedure  for  spiral  consistency  enforcement  avoids  the 
problem  of  downgrading  or  major  sanitization  while  at  the  same 
time  providing  essentially  the  same  application  safeguards.  The 
verification  process  cannot  release  data  above  the  user’s  classifi¬ 
cation  level.  Its  purpose  is  to  ensure  that  the  recommendations 
in  the  primary  result  are  safe  and  consistent  with  the  technical 
requirements  of  the  application.  While  the  verification  process 
does  operate  at  the  higher  level,  its  output  is  through  the  very 
narrow  yes/no  channel. 

In  particular,  the  only  data  that  is  a  candidate  for  release  is 
the  primary  result  P ,  and  it  was  generated  at  the  user’s  level. 
Whon  the  primary  result  is  not  deemed  consistent  or  safe,  then 
it  would  be  withheld.  Furthermore,  if  the  simple  absence  of 
output  is  itself  a  covert  channel  of  concern  in  the  application, 
then  a  cover  story  could  be  offered. 

A  cover  story  is  an  explanation  that  can  be  presented  at  a  low 
classification  level  to  explain  conditions  that  actually  arise  from 
higher  level  data.  Such  a  cover  story  must  be  generated  by  a 
trusted  subject.  For  example,  if  flights  to  Iran  are  not  visible 
due  to  their  being  classified  at  a  higher  level,  some  explanation 
might  be  offered  to  divert  attention  from  the  actual  reason  that 
such  flights  are  not  shown.  The  cover  story  might  be  that  the 
airfield  for  Iran  is  undergoing  repair.  In  general,  a  prespeciflcd 
set  of  cover  stories  might  be  used,  with  limited  run-time  tailoring 
done  by  a  trusted  subject.  It  is  worth  noting  that  the  use  of  cover 
stories  is  similar  to  sanitization  via  adding  noise  (perturbing  the 
data). 

2  A  Rule-Based  System  for  Multilevel  Clas¬ 
sification 

As  multilevel  database  systems  become  available,  the  process  of 
classifying  large  volumes  of  data  at  appropriate  levels  will  be¬ 
come  increasingly  complex.  Not  only  will  the  initial  database 
need  to  bo  give  1  classification  labels,  but  new  data  entering 
the  system  will  require  classification.  Manual  classification  of 
massive  amounts  of  new  data  likely  will  not  be  feasible.  Titus 
automated  techniques  will  be  needed. 

A  good  framework  for  such  automated  techniques  would  be  a 
rule-based  system  in  which  the  rules  recommend  classification 
labels  based  upon  the  type  of  data,  its  source,  value,  and  pos¬ 
sible  relationships  to  other  data.  Suclt  rules  have  been  called 
classification  rules  by  Denning  in  the  SoaView  project  [3|,  We 
call  the  ovciai!  system  v,hich  produces  classification  labels  for 
data  the  Classifier  Tool.  This  Classifier  could  assist  a  security 
oliicer  or  database  administrator  with  the  classification  process. 
An  analysis  of  other  aspects  ©t  such  a  tool,  including  the  prob¬ 
lem  of  accounting  for  logical  inferences  by  users,  can  be  found 
in  Murgcnstern  |4). 

‘Although  wc  jus  addreuiiiK  mandatory  lecurity  hern,  thii  procedure  can 
ha  g-uoraliied  to  Include  discretionary  security  The  primary  rr.iuU  P  depends 
upon  data  and  rules  to  v-hich  the  user  legitimately  hoe  occrta,  while  the 
verification  process  can  opei  ate  at  a  higher  ci<uiifkatiou  and  with  additional 
access  privileges. 


This  Classifier  would  determine  which  of  the  potentially  large 
set  of  classification  rules  may  be  applicable  to  data  about  to  en¬ 
ter  the  database,  and  would  evaluate  each  rule  to  determine  a 
classification  label  for  the  data.  In  particular,  it  could  find  that 
several  such  rules  apply,  and  that  different  rules  recommend  dif¬ 
ferent  labels  —  thereby  giving  rise  to  the  problems  we  investigate 
below. 

The  problem  of  write-down  will  arise  if  the  tool  consults  data 
at  several  classification  levels,  or  if  classification  rules  are  them¬ 
selves  assigned  classification  levels.  In  these  cases,  the  tool  may 
need  to  operate  at  the  least  upper  bound  (lub)  of  such  levels.  If 
the  tool  assigns  a  classification  that  is  less  than  thm  lub,  then 
writing  the  label  at  a  lower  level  would  be  a  form  of  write-down, 
which  might  be  considered  a  potential  violation  of  security. 

2.]  Classification  Rules 

Classification  rules  may  apply  to  data  objects  at  several  lev¬ 
els  of  granularity,  including  relation,  tuple,  or  element  level. 
Mandatory  security  requires  ‘hat  in  order  for  information  D  to 
be  available  to  user  U ,  th  .uthorization  of  U  must  dominate 
the  classification  label  of  D  —  which  may  be  represented  as 
U.tevet  >  D.level,  where  U.level  denotes  the  authorization  level 
of  user  U  and  D.level  denotes  the  classification  of  data  D.  The 
term  level  is  traditional  terminology  although  it  should  be  noted 
that  the  set  of  classification  “levels"  actually  forms  a  lattice  due 
to  compartmcn  tali  nation  of  data. 

We  assume  completeness  of  the  classification  rules,  so  that  at 
least  one  rule  is  applicable.  The  now  data  to  be  classified  will 
be  referred  to  as  the  target  data.  To  determine  which  rules  need 
to  be  executed  for  some  new  target  data,  relevant  rules  first  are 
selected  based  upon  the  nature  of  the  target  data,  such  as  the 
the  type  of  the  data,  etc.  Rules  are  selected  as  relevant  without 
referring  to  current  date  values  stored  in  the  database.  Then 
the  condition  part  of  each  relevant  rule  is  evaluated  relative  to 
actual  data.  In  general,  t  he  condition  parts  for  only  some  of  those 
rules  wili  be  fully  satisfied  —  these  are  the  executable  rules.  We 
assume  here  that  several  rules  could  be  executed  Tor  one  data 
object. 

If  the  executed  rules  access  existing  data  at  different  levels . or 

if  the  rules  themselves  are  class ; fled  differently  —  then  additional 
questions  arise: 

•  If  high  level  rules  and  data  need  10  be  consulted  to  rec¬ 
ommended  a  lower  level  classification  label,  we  have  the 
problem  of  writing  down  when  generating  the  low  label. 
Can  this  write-down  be  avoided? 

•  If  the  recommended  labels  are  different,  which  label  or 
combination  ol  labels  should  be  used?  Generally,  taking 
the  least  upper  bound  of  the  labels  would  be  appropriate, 
although  oil  er  possibilities  might  be  to  prioritize  tiu)  rules 
or  to  signal  an  inconsistency  requiring  manual  intervention. 
The  decision  may  be  specific  to  the  application. 

In  the  next  section,  wc  focus  on  the  first  question  above,  namely 
can  we  avoid,  write-down  when  high  level  rules  end  data  need  to 
be  consulrcd  to  determine  that  a  lower  lrrel  classification  would 
be  appropriate? 
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2.2  The  Write  Down  Problem 

Since  the  Classifier  will  need  to  write  labels  at  all  levels  including 
system  high,  one  might  wish  to  operate  the  Classifier  at  system 
high.  However,  writing  labels  at  lower  levels  then  would  present 
the  write-down  problem. 

There  are  two  cases  where  the  classification  process  may  need 
to  operate  at  a  high  level  in  order  to  properly  determine  that 
the  label  (or  some  data  should  be  at  a  lower  level.  For  the  first 
case  consider  that  all  the  rules  are  unclassified.  If  tt  rule  Is  given 
some  target  data,  then  the  label  it  assigns  may  depend  upon  the 
classification  levels  of  related  data  that  the  rule  needs  to  access. 
Thus  if  tlie  rule  Is  run  at  a  low  level,  it  may  not  be  able  to  see 
such  related  drllu,  and  thus  may  incorrectly  conclude  that  tho 
label  should  lm  lull . 

It  might  seem  necessary  then,  for  the  rule  to  be  run  at  a  higher 
level,  ao  that  it  eould  detect  tills  related  data  and  make  the 
correct  decision  to  assign  a  high  label  to  the  target,  However, 
if  the  rule  is  run  at  this  higher  level  but  there  Is  rio  high  data 
which  is  related,  then  the  rule  may  appropriately  recommend 
a  iow  level  label,  Since  the  rule  Is  operating  at  a  high  level, 
generation  of  a  low  level  label  creates  the  write-down  problem. 

The  second  case  arises  if  the  classification  rules  themselves  are 
classified,  with  different  rules  having  potentially  different  clas¬ 
sifications,  For  example,  sensitive  values  may  be  represented 
in  some  rules  in  order  to  assign  higher  labels  when  these  val¬ 
ues  arise.  Such  rules  might  be  classified  higher  than  other  rules 
because  of  the  contents  of  these,  rules. 

in  this  ease  then,  the  relevant  high  level  rules  must  be  invoked  to 
delertnine  if  their  value-dependent  conditions  are  satisfied  and 
whether  they  recommend  a  high  Is  bid.  If  such  rules  do  not  rec¬ 
ommend  a  high  label,  writing  a  lower  label  would  be  a  form  of 
write-down  from  this  higher  level  process. 

The  approach  presented  below  addresses  both  oi'  these  cases.  It 
considers  the  level  at  which  the  classification  process  is  execut¬ 
ing  regardless  of  whether  this  arises  from  the  level  of  related 
■  l.i t u  which  needs  to  be  inspected  or  whether  the  rules  them* 
.■■wives  ace  classified  at  this  level. 

2.3  The  ciplrul  Classification  Process 
One  might,  consider  as  a  first  step  in  addressing  tiis  write-down 
problem  the  creation  of  a  separate  Classifier  process  at  each  se- 
cupty  level,  finch  Classifier  process  would  be  allowed  to  write 
label'  only  for  its  current  level  of  operation-  A  Classifier  pro¬ 
cess  could  utilize  rule,,  and  access  data  at  iower  lev-; ’a  but  not  at 
higher  levels  ■!!;. 

How:  ter,  (hi::  approach  does  not  solve  the  write-down  problem. 
1  b:,i,  the  derision  as  to  whether  some  target  data  warrants  a  low 
or  a  high  classification  could  logically  depend  upon  the  presence 
or  absence  of  higher  level  data,  Secondly,  the  labeling  decision 
mu,  depend  upon  whether  any  higher  level  rules  exist  that  apply 
to  thU  turn-si  data  That,  a  low  level  rule  is  applicable  dost  not. 
prevent  a  higher  level  rule  from  knowing  more  and  mandaC’ng  a 
high  label. 


In  both  cases  only  a  high  level  process  can  determine  whether 
high  level  data  and/or  high  level  rules  apply.  Hence  it  would 
still  appear  that  write-down  from  a  Classifier  process  operating 
at  a  high  level  is  needed  to  fully  ensure  that  the  labels  assigned 
to  data  take  into  account  all  relevant  classification  criteria. 

We  propose  a  spiral  classification  procedure  which  essentially 
avoids  tho  write-down  problem.  Since  it  executes  a  classifier 
process  at  successively  higher  levels,  starting  with  the  lowest 
level,  it  creates  a  “spiraling"  effect,  The  properties  necessary  for 
spiral  classification  are: 

Spiral  Clagsiflcatloiv. 

1.  Monotoniclty:  A  classifier  process  is  executed  first  at 
the  lowest  classification  level,  and  then  executed  at  each 
of  the  other  classification  levels.  The  order  of  considering 
tho  levels  must  be  In  a  monotonically  non-decreasing  or¬ 
der  In  the  classification  lattice.  That  is,  each  subsequent 
classification  level  to  be  examined  must  either  dominate  or 
be  non-comparable  with  each  preceding  classification.  A 
separate  executable  process  could  be  created  at  each  clas¬ 
sification  level. 

2.  Atomicity:  The  data  to  be  classified  is  not  made  available 
to  users  until  the  entire  spiral  classification  procedure  is 
completed  at  all  levels.  This  requirement  will  be  satisfied 
if  the  overall  process  is  atomic.  That  is,  either  it  completes 
without  error,  or  else  the  system  ensures  that  there  h  no 
evidence  of  an  incomplete  execution.  Atomicity  ensures 
that  if  high  level  rules  assign  a  higher  classification  label 
than  previously  executed  lower  rules,  thon.this  higher  level 
label  will  take  precedence  before  any  data  access  is  allowed. 
This  approach  maintains  the  tranquility  property  of  Bell 
and  LaPadula  [l],  because  users  will  be  presented  with  an 
unchanging  classification  for  each  data  object. 

3.  Least  Upper  Bound:  When  the  classifier  recommends 
a  new  classification  label,  it  should  be  at  the  level  the  clas¬ 
sifier  is  then  operating  at.  Thus  there  is  no  write-down 
from  any  iteration  of  ths  classifier.  If  the  data  a1  ready  has 
a  current  lauol  (c),  then  the  least  upper  bound  (lub)  of  the 
new  label  (A)  and  the  current  label  (c)  .should  be  used,  if 
we  have  a  strict  hierarchy  of  levels,  or  if  the  h  dominates 
c,  then  the  lub  is  just  h.  Thus  any  writing  of  classification 
labels  by  the  classifier  raises  the  data  object  to  at  least  the 
level  at  which  the  classifier  is  executing. 

-I.  Trusted  Kernel:.  Since  each  Iteration  oi  the  classifier  is  at 
a  single  level  theie  is  no  write  down.  The  outermost  super¬ 
visory  process  that  initiate*  each  deration  must  be  trustee! 
lo  execute  the  levels  in  monoUmically  non-decreasing  or¬ 
der,  to  prevent  rebate  of  data  during  the  process,  and  to 
allow  labels  Lo  be  revised  only  upward. 

We  observe  that  atomicity  guarantees  that  data  is  not  released 
until  it  has  been  given  the  highest,  level  label  that  is  applicable, 
and  then  it  is  released  only  ut  that  level.  The  trusted  kernel 
guarantees  that  intermediate  stages  of  the  iterative  process  do 
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not  release  data.  Thus  lower  level  rules  do  not  release  data, 
they  only  could  cause  the  classification  labels  of  the  data  to  rise. 
We  also  note  that  the  trustworthiness  of  a  rule  !s  essentially  the 
integrity  level  of  the  rule  rather  than  its  sensitivity. 

The  spiral  classification  process  can  be  applied  during  initial 
loading  of  the  database  to  label  all  the  data.  During  run-time 
it  can  be  reexecuted  periodically  to  label  new  data  —  each  such 
execution  must  be  in  a  trusted  partition  and  must  be  atomic.  An 
external  concern  is  that  new  data  should  arrive  through  a  secure 
route  so  that  it  is  not  accessible  until  it  iseiassified  appropriately 
(for  example,  sensor  datiy  could  be  encrypted  at  the  source  and 
decrypted  when  It  enters' the  classifier). 

t  I 

Thus  far  it  has  been  assumed  that  a  new  Classifier  process  is 
created  at  each  level.  One  might  wish  to  iterate  a  single  Classi¬ 
fier  process  at  successively  higher  lovels,  rather  than  creating  a 
new  process  at  each  level.  Since  the  spiral  is  upward  to  higher 
levels,  it  might  be  considered  adequately  safe  for  some  systems. 
However,  due  to  the  partially  ordered  nature  of  the  classification 
lattice,  care  must  be  taken  regarding  non-comparable  levels.  In 
particular,  use  of  the  same  process  at  such  non-comparable  lev¬ 
els  creates  the  danger  of  writ  c-ac  rose  -  which  is  the  counterpart 
of  write-down  but  for  non-comparable  classifications. 

3  Conclusion 

Both  spiral  classification  of  data  as  well  as  spiral  consistency  of 
output  from  rule-based  expert  systems  share  the  spiral  process 
of  iteratively  executing  ut  two  or  more  levels.  The  monotonically 
non-decreasing  order  of  executing  the  levels  ensures  that  data  is 
not  passed  from  a  high  level  to  a  low  level  because  the  higher 
level  executes  later. 

The  spiral  process  further  decomposes  the  computations  at  dif¬ 
ferent  levels  in  such  a  manner  that  interactions  among  levels  are 
essentially  eliminated.  Only  the  trusted  kerne!  persists  over  the 
multiple  iterations. 

We  have  discussed  how  the  spiral  process  can  ensure  consistency 
of  the  results  from  a  multilevel  expert  system  in  that  a  low  level 
user  will  not.  be  given  grossly  inconsistent  or  harmful  advice  due 
to  lack  of  access  to  higher  level  rules  and  data  This  spiral  pro¬ 
cess  executes  at  two  levels,  the  user’s  level  and  a  higher  system 
verification  level.  We  noted  that  the  remaining  low  frequency  bi¬ 
nary  (yes/no)  channel,  with  one  bit  per  problem  solution,  could 
be  furt  her  reduced  by  use  of  cover  stories. 

Wo  then  considered  how  a  spiral  process  could  be  utilized  to 
execute  classification  rules  without  write-down  so  as  to  assist  a 
security  officer  or  database  administrator  by  generating  classifi¬ 
cation  labels  for  data. 
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Abstract 

Issues  relevant  to  construction  of  a  security  monitor  for 
use  as  Intrusion  Countermeasure  Equipment  to  detect  sys¬ 
tem  intrusions  and  abuse  by  legitimate  users  are  presented. 

The  monitor  compares  current  activity  against  adaptive 
user  work  profiles  and  system  security  policy,  and  alerts 
the  security  operator  to  any  significant,  deviations.  This 
approach  discriminates  data  aggregation  attacks  and  in- 
shier  almse  as  effectively  us  it  detects  Intruders,  and  also 
supports  a  standard  commercial  system  as  well  as  a  system 
customised  lor  security.  Design  details  rover  principles  of 
an  analysis  engine  tu  extract  system  policy  violation  and 
historically  abnormal  usage  patterns  from  the  audit  trail, 
a  high  level  design  of  the  security  monitor,  u  discussion 
of  inslallnlion  specific  concerns,  and  directions  for  semi¬ 
automatic  application  its  a  detective  device. 

1  Introduction 

While  the  technology  needed  to  design  mid  verily  secure  machines  is 
advancing  steadily,  there  now  exists  n  massive  Installed  base  quietly 
and  efficiently  performing  the  everyday  tasks  needed  to  support  the 
government  and  con  .oerclal  infra-structure.  It  is  not  practical  to  re¬ 
place  all  sensitive  sy-trms  subject  to  intruder  or  aggregation  threats 
with  secure  systems,  yet  neither  Is  there  much  hope  for  retrofit  security 
on  commercial  operating  systems.  Integrating  a  reference  monitor  jl] 
which  is  pervasive  enough  to  prevent  bypass  is  difficult  and  disruptive, 
robbing  both  petTo'inriiice  and  functionality. 

The  challenge  is  to  develop  peripheral  Intrusion  Countermeasure 
Equipment  (ICE)  for  the  mainstream  1)1*  shops  width  has  a  minimal 
impact  mi  the  system,  yet  is  deeply  rooted  in  the  system  to  difo\MW 
age  bypass.  Analysis  of  the  information  provided  by  existing  mid  t 
facilities  tits  these  criteria.  Modification  of  the  operating  system  or 
hardware  is  not  required,  performance  Is  not  degraded  severely,  and 
the  mechanisms  are  extremely  hard  to  bypass;  accounting  information 
is  collected  deep  within  the  operating  systems  -mil  has  been  supported 
by  special  hardware  features  for  decades.  This  is  especially  appro¬ 
priate  lor  Installations  with  sensitive  datu  vulnerable  to  aggregation 
ntia.-ks  bill  with  scant  resources  to  spare. 

I  lie  authors  have  worked  on  design  and  development  of  two  audit 
analysis  ICE  systems.  Tills  paper  contains  our  thoughts  on  building 
a  security  monitor  with  adaptive  user  work  profiles,  based  upon  our 
research  and  experience  and  Considering  the  line  work  of  our  peers 
presented  at  this  and  other  Ibrums(l0|.  The  goal  of  this  paper  is  to 
lend  ideas  and  assistance  to  current  and  future  development  of  security 
monitors  or  ICE. 

2  Approach 

This  paper  presents  a  design  for  ICE  based  upon  a  Usage  monitor 
which  compares  current  activity  against  adaptive  user  work  profiles 
and  system  security  policy.  Profiles  of  work  patterns  character; /•big 
individual  users  can  be  derived  from  audit  trail  analysis.  Deviation 
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from  these  work  profiles  may  indicate  an  intrusion  or  insider  abuse. 
The  monitor  const! nets  and  maintains  the  historical  work  profiles  for 
each  tisur  and  compares  them  witli  current  activity  in  real  time.  The 
system  security  policy  is  regarded  as  a  universal  profile  to  which  all 
users  must  conform. 

Users  have  recognizable  usage  patterns  which  leave  a  distinctive 
signature  on  the  audit  trail.  Naturally  some  users  are  more  regular 
lint!)  others,  but  for  some  large  percentage  of  users  the  patterns  will 
be  clear  enough  to  bo  extracted  by  some  analysis  uugine(6j  [9],  Unfor¬ 
tunately,  detecting  Intrusions  and  insider  abuse  by  analysis  of  audit 
Mails  is  not  a  trivial  exercise.  A  hum  an  cannot  readily  review  a  sys- 
1cm  audit  trail  and  isolate  characteristic  user  work  patterns.  What  is 
needed  to  make  audit  trails  useful  for  security  purposes  is  ICE  to  assist 
in  the  detection  of  anomalous  activity.  Ideally  such  a  tool  Would  reli¬ 
ably  alert  l lie  operator  when  intrusion  or  abuse  was  actually  occurring 
on  the  computer  system.  Realistically,  the  tool  will  alert  the  security 
operator  to  improper  or  abnormal  activity,  in  dose  to  real  time,  mid 
assist  in  review  and  investigation  of  anomalous  events. 

Review  of  statistically  deviant  activity  is  tractable  and  manageable 
for  large  systems  in  real  lime.  An  analysis  engine  performing  this 
task  can  detect  abnormal  or  improper  behavior  by  1)  checking  tiro 
audit  records  for  direct  violation  of  the  system  security  policy  and 
2)  comparing  a  statistical  analysis  r>[  the  audit  trail  ;n  -ust  historical 
work  profiles.  A  user  work  profile  might  consist  of  a  broad  description 
derived  from  Ids  or  her  job  description,  augmented  with  a  continually 
updated  summary  of  the  user’s  individual  historical  activity.  There 
may  also  be  group  or  system  wide  tis.tge  profiles.  Some  actions  or 
sequences  are  implicitly  suspicious,  dearly  deseving  the  operator's 
iillention  without  reference  to  the  user  profile. 

Audit  unalysin  ICE  should  allow  (he  security  officer  to  cieate  tem¬ 
plates  defining  the  tillers  and  statistical  measures  to  apply  to  the  au¬ 
dit  trail,  and  the  relative  significance  of  deviations,  l-'nrtliei  ,  the  basic 
analysis  engine  built  for  audit  reduction  and  ptolile  updating  nut  serve 
as  a  powerful  detective  tool  for  investigation  of  suspicious  activity. 

Tlie  realm  of  information  useful  to  a  comprehensive  audit  reduction 
and  analysis  tool  cun  Ire  sopanilod  into  the  following  five  categories; 

System  Specific 

/dcv/ltya  is  connected  to  n  cull  out  modem. 

/lib  Is  a  directory  of  read-only  libraries. 

I’olicj 

(xissivif  is  a  security-related  romimiuii. 

Users  tuny  not  send  system  data  files  to  a  printer. 

User  Activity 

Ms.  Smith  lias  never  previously  logged  in  late  at  night. 

Mr.  Jones,  in  accounting,  lias  never  used  the  compiler  before. 

User  Specific 

Mr.  White  is  on  a  three  week  vacation. 

Mr.  Black  is  terminated  as  of  July  4th. 

Worldly 

The  company  will  be  dosed  over  the  Christmas  Holiday. 

Research  dept.  Is  finishing  up  a  proposal,  expect  late  nights. 
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3  Theoretical  Framework 

Audit  trail  analysis  ICE  allows  a  System  Security  Officer  to  develop  a 
rule  base  describing  system  policy,  user  job  descriptions,  and  templates 
for  construction  of  historical  user  profiles.  These  rules  define  a  set  of 
conditions  which  match  some  audit  records,  what  data  is  desired  from 
these  records,  how  to  interpret  this  data,  and  where  to  record  the 
derived  information.  A  rule  base  for  ICE  need  not  be  the  colossal  web 
of  experience  that  is  seen  in  an  expert  system,  and  the  rules  can  be  laid 
down  at  a  high  level  which  is  accessible  to  human  review  or  discussion. 


3.1  Characterizing  Intrusions  and  Insider  Abuse 


Intrusion  and  insider  abuse  is  defined  here  as  the  use  of  a  computer 
system's  resources  from  which  you  would  normally  bo  prevented  or 
for  which  you  do  not  have  privilege  and  ethical  reason  to  use.  The 
following  is  a  taxonomy  of  misuse  we  are  concerned  with: 


Trespassing 
tourist  hacker 
Browsing 

passive 

active 

aggregation 

inferencing 

Malfeasance 

leakage  of  classified  data 


Access  the.  system 
breaks  in  as  hobby 

Look  at  the  system 

scavenging  with  goal  in  mind 
accumulation  increases  Vulue 
distillation  increases  value 
Misuse  the  system 


lion-work  related  use  of  system 


Theft  Steal  from  the  system 

general  software 
specific  sensitive  data 

Modification  Change  the  system 

data 

data  diddling 
false  data  entry 
programs 

Trojan  horses,  logic  bombs 
round-olf  attacks 
viruses 

system  behavior 

access  rights/password  files 

ownership 

accounting 

Destruction  Destroy  the  system 

data 

programs 

accounts 

Denial  of  service  Degrade  service 

locking  accounts 
degradation  of  system  response 


Note  that  misuse  may  be  accidental,  A  system  flaw  may  give  un¬ 
expected  access  to  a  well  meaning  user.  Mistyping  could  produce  an 
unintentional  malicious  result.  A  new  user  may  even  be  unaware  of 
certain  aspects  of  the  system  policy.  We  make  no  attempt  to  divine 
intent  or  malevolence;  the  System  Security  Officer  must  use  the  inves¬ 
tigative  tools  to  determine  this. 

3.2  Features 

Identifying  these  kinds  of  misuse  requires  a  sophisticated  review  of  the 
audit  trail.  The  idea  is  to  measure  particular  features  of  the  audit  trail, 
and  compare  these  measurements  with  the  historical  activity  record 
for  tlie  same  user  This  comparison  does  not  directly  reveal  misuse, 
but  rather  indicates  a  degree  of  concern  or  a  warning  count.  Some 
combinations  of  violations  are  cause  for  more  concern  than  the  sum  of 
the  parts  would  indicate,  so  detected  features  should  he  considered  in 
context. 


This  list  describes  the  kind  of  activities  which  should  be  recognised, 
measured,  and  evaluated  for  detection  of  intrusion  or  Insider  abuse. 
These  features  are  examples,  not  as  a  definitive  list  or  a  taxonomy. 

Time 

time  activity  takes  place 
time  of  day 
day  of  week  or  month 
date 

length  of  session 
time  between  actions 

last  use  of  this  command 
last  action  in  a  class 
last  action  of  any  type 
Command 

first  use  of  a  command 
frequency  of  a  command  in  a  session 
job  rate 
job  mix 

ratio  of  one  command  versus  another 
ratio  of  one  command  versus  total  activity 
multiple  login 

specific  command  sequences 
access  to  certain  files  or  directories 
oilier  common  command  sequences 
permission  denied,  file  or  command 
login  denied 
invalid  password 
unusual  terminal 
multiple  login 
Resource  Usage 

CPU  cycles  per  minute 
CPU  cycles  per  command 
Disk  space 
Virtual  memory 
Printers 
General  I/O 


off  shift,  lunchtime 

status  reports 

end  of  quarter  activity 


idle  time 


3.3  An  Abstract  Model  for  the  Analysis  Engine 

The  key  to  successful  audit  trail  analysis  is  constructing  an  applicable 
system  security  policy  and  locating  the  key  discriminators  in  user  work 
histories.  Building  a  successful  analysis  engine  requires  a  broad,  rich 
language  for  description  of  general  system  activity.  Our  effort  started 
out  with  an  approach  laid  out  by  Denning  [3]  and  we  adaptod  it  to  fit 
our  experience  on  actual  systems.  This  work  outlines  a  small  language 
for  processing  of  audit  records,  including  definition  of  variables  which 
apply  some  statistical  analysis  to  audit  records  selected  by  pattern 
matching.  The  variables  describe  which  features  of  the  audit  trail  we 
want  to  measure  and  evaluate.  The  reader  should  be  familiar  with 
Denning's  work  to  get  the  most  out  of  this  section. 

Our  Initial  research  was  based  on  our  knowledge  of  audit  informa¬ 
tion  available  under  Unix  and  IBM  MVS  systems,  considering  a  dozen 
scenarios  of  intrusion  and  insider  abuse.  We  found  that  analysis  of 
individual  actions  (single  audit  records)  would  not  reliably  discrimi¬ 
nate  many  of  our  sample  scenarios.  We  reworked  the  feature  defini¬ 
tion  language  to  better  support  sequences,  combinations,  and  timing. 
These  capabilities  extend  the  descriptive  power  to  effectively  deal  with 
problems  one  encounters  during  system  modeling.  We  also  added  his¬ 
tograms,  a  special  storage  clast  to  capture  historical  time  relevance. 

3.3.1  Event* 

Events  are  the  actions  which  may  be  measured.  Events  are  composed 
from  audit  records.  Events  may  be  represented  by  a  single  audit  record 
or  a  sequence  of  records. 

Single.  Records  will  be  treated  u  events  when  one  or  more  of  the  data 
fields  match  a  specified  pattern.  The  pattern  description  must 
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be  flexible,  including  wildcards,  character  ranges,  and  alternates. 

Sequence.  Sequences  are  meant  to  capture  a  single  event  which  is 
broken  into  many  audit  records.  Some  systems  associate  a  string 
of  actions  with  a  single  parent  process,  and  this  inform  at  ion  may 
be  available  in  the  audit  trail. 

3.3,2  Metrics  and  Measures 

Metrics  are  the  “yardsticks”  for  various  events  we  arc  interested  in. 

Measures  are  numbers  which  quantify  activities.  Applying  a  metric  to 

a  record  sequence  produces  a  measure,  a  single  number  indicating  how 

much  or  how  many. 

Counter  Cycle.  A  counter  metric  tallies  the  occurrences  of  an  event 
within  a  time  period  (see  Cycle  Structuic).  A  counter  could  track 
sessions  during  a  day,  number  of  times  a  transaction  is  executed 
during  a  session,  or  failed  logins  during  three  minutes. 


3.3.5  Evaluation 

Evaluation  displays  violations,  determines  degree,  and  provides 
weighting  between  the  features. 

Violation.  There  is  a  violation  when  a  measure  exceeds  the  profile. 
The  warning  count  of  the  violation  increases  as  the  measure 

grows. 

Weighting.  When  a  violation  occurs,  the  significance  is  computed  by 
a  simple  formula.  This  formula  includes  a  scaling  factor,  which 
takes  into  account  the  domain  of  the  measure  and  the  relative 
importance  in  this  installation  of  the  violation.  The  weighting 
formula  produces  the  warning  count  for  each  feature. 

Alarms.  Some  violations  deserve  more  than  simply  increasing  the 
significance.  Alarms  are  presented  separately,  in  addition  to  the 
warning  count, 


Quantity  Cycle.  A  quantity  metric  measures  the  amount  of  resource 
consumed  by  events  of  a  specified  type  during  a  time  period  (sec 
Cycle  Structure).  Resources  are  reported  in  a  variety  of  units. 
Quantities  ore  in  like  units,  for  evaluating  anything  from  CPU 
milliseconds  to  printer  page  counts. 


Grouping.  Melafeaturcs  work  with  the  computed  warning  counts  of 
other  features,  compared  against  limits.  This  grouping  of  fea¬ 
tures  allows  increasing  the  warning  count  when  multiple  related 
violations  are  in  evidence.  Grouping  increases  the  session  warn¬ 
ing  count  whenever  several  features  in  a  set  are  present. 


Ratio  Cycle.  Ratio  of  one  record  type  compared  with  another  over 
a  time  period  or  session  (see  Cycle  Structure). 

(fyclc  Structure.  A  cycle  structure  is  the  structure  used  to  store  coun¬ 
ters  and  quantities.  A  cycle  refers  to  the  occurrences  of  some  event 
within  a  repeating  time  interval,  These  Intervals  are  exported  to  be 
stored  as  segments  within  a  cyclic  period  such  as  hours  in  a  day,  days 
in  a  week,  months  in  a  year.  A  cycle  may  also  be  the  variable  length  of 
time  between  login  and  logout  called  a  Session,  The  period  is  divided 
into  equal  segments,  and  a  measurement  is  made  for  each  of  these  seg¬ 
ments.  We  often  refer  to  these  as  Histograms  because  the  structure  is 
easily  displayed  or  conceived  as  a  strip  chart. 

3.3.3  Models 

Models  are  the  functions  which  compare  the  profile  value  with  the 
measured  values,  and  produce  >v  violation.  The  violation  is  multiplied 
by  the  Weighting  (below)  to  produce  a  scaled  warning  count  for  the 
time  period.  Separate  time  periods  in  the  cycle  are  added  together  to 
produce  the  feature  warning  count. 

Limit.  The  measure  value  for  each  feature  is  compared  against  the 
value  in  the  profile. 

Deviation.  The  basic  average  is  mnintained  to  determine  deviation 
from  the  mean.  To  save  space,  a  close  approximation  can  he 
computed  with  the  old  average  and  the  new  value.  The  length 
of  the  history  needs  to  he  recorded  to  ensure  proper  weighting 
of  the  new  value  into  the  average. 

Variance.  Variance  is  a  computation  of  consistency  over  time. 
Whereas  Deviation  compares  the  measure  for  one  time  slot 
against  the  profile  value,  Variance  compares  the  time  slot 
against  adjacent  time  slots. 


3.d  Writing  system  and  user  profiles 

Gonslructing  and  updating  profiles  of  user  work  patterns  and  the  sys¬ 
tem  security  policy  is  a  sophisticated  mid  detailed  task.  A  database 
query  language  such  as  SQL  is  convenient  for  setup  and  investigation, 
but  the  overhead  of  a  database  query  language  is  too  high  for  run¬ 
time  analysis  ami  profile  updating.  The  installation  and  maintenance 
of  this  design  needs  a  small  language  for  definition  of  the  desired  fea¬ 
tures.  The  paragraphs  below  are  not  a  complete  language,  but  n  terse 
presentation  of  the  concepts  involved. 

The  elements  of  profile  description  are  audit  records,  event  defini¬ 
tion,  feature  definition,  group  definition,  and  profile  definition.  These 
elements  build  upon  eticli  other  as  follows: 

The  structure  of  an  uurlit  record  is: 

Subject:  (user)  (terminal)  (modem) 

Objects:  [files]  (directories)  (ports)  (peripherals) 

Action:  [command]  (parameters)  [error  codes) 

Resources:  ((’I’ll  time]  (I/O  counts]  [page  counts]  etc. 

The  structure  of  all  mill  definition  is: 

(Event- name)  [Field(s).Patlorii(s)),,. 

or 

[Event*  name)  [Event  (s)]... 

The  structure  of  n  finturc  definition  is: 

[Fcttturc-nnmej  (Event)  (Metric)  (Modelj  (Update) 

(Cycle)  (Period]  (Weighting)  (Initial) 
or 

jFentiire-name)  (Eeat.ure(s)]... 

The  slliieluro  of  a  group  definition  is: 

(Group-name)  (Eeature(s)j... 

The  structure  of  a  profile  definition  is: 

(User-name)  [Faaturefs)-or-tiroup(s)j  ... 


3.3.4  Profile  Updates 

Fixed.  A  fixed  value  may  be  used  Tor  Limit  processing. 

High  Water  Mark.  A  fixed  value  may  he  used  for  Limit  or  Vari¬ 
ance  processing.  Remember  that  the  SSO  is  expected  to  verify 
substantial  changes.  Useful  for  locating  reasonable  fixed  limits. 

Decaying.  A  decaying  value  may  be  used  for  Limit  or  Variance 
processing.  A  decaying  value  is  a  high  water  mark  that  slowly 
moves  back  down. 

Average.  The  average  over  time  is  maintained  for  Deviation  or 
Variance  processing. 


Audit  records  are  reformatted  by  the  ICE  before  processing.  Pattern 
mulching  on  audit  record  fields  is  not  relevant;  the  authors  prefer 
the  extended  regular  expressions  familiar  to  users  of  UNIX  ttjrvp,  hut 
should  include  wildcards,  character  ranges,  and  full  regular  expression 
alternates.  The  first  form  of  an  event  pattern  matches  one  or  more 
fields  in  an  audit  record.  The  second  form  is  a  sequence  of  audit 
records,  each  defined  as  an  single  record  event.  A  group  is  an  alias 
for  multiple  features  (features  may  lie  in  several  groups).  The  profile 
definition  is  used  to  create  the  actual  profile  data  structure.  This  data 
structure  is  then  maintained  by  the  profile  updater. 

A  new  user  profile  contains  a  list  of  the  features  and  a  copy  of 
the  Limits  referred  to  in  the  profile  definition.  These  limits  may  be 
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changed  over  time  by  the  Profile  Updater,  depending  upon  the  Up¬ 
date  held  from  each  feature  definition  (sec  Profile  Updates),  The  profile 
also  contains  a  running  total  of  the  warning  count  in  evidence  at  the 
end  of  each  session,  which  is  decayed  over  time  and  usage  in  the  same 
manner  as  a  Decaying  profile  update. 

The  session  warning  count  is  the  sum  of  all  feature  warning  counts 
during  a  session.  This  value  indicates  the  calculated  significance  of  all 
profile  violations.  The  further  out  of  profile  a  user  is  on  any  particular 
feature,  the  higher  that  feature  warning  count  will  bo.  Out  o{  profile 
is  defined  as  being  over  Limit,  outside  Deviation  from  historic  mean, 
or  excessive  Variance  from  adjacent  time  periods,  depending  upon  the 
Model.  Since  these  differing  counts  are  summed  for  evaluation,  the 
Weighting  of  each  feature  serves  two  purposes:  weighting  indicates 
the  relative  significance  of  each  feature  and  idso  converts  each  feature 
to  the  same  scale, 

3.5  Sample  Feature  Definitions 

Login  Time,  System  Policy.  Users  at  Acme  Widget,  lac.  login 
during  shift  hours  only,  but  may  log  in  and  out  several  times  a  day. 
This  feature  watches  for  the  extraordinary  late  night  login.  The  event 
is  the  time  stamp  from  a  login  record.  The  measure  is  a  counter,  on 
a  daily  cycle,  half  hour  periods.  The  update  is  decaying,  so  that  the 
profile  adjusts  to  the  work  habits.  The  model  is  variance  because  we 
arc  searching  for  a  an  event  well  away  from  other  recorded  events.  The 
weighting  is  high,  as  this  is  exported  to  be  a.  strong  discriminator  on 
the  target  iu  question.  A  login  at  a  new  lime  but  close  to  the  historical 
times  would  lie  flagged,  but  with  a  lower  warning  count;  thus  a  worker 
who  stays  a  bit  late  one  day  to  finish  one  last  thing  will  be  noticed, 
but  not  heavily  stressed. 

Job  Frequency,  Accounting,  The  accounting  staff  at  Acme  uses 
the  database  for  inventory  control  ami  does  a  far  amount  of  report  gen¬ 
eration,  but  they  are  not  so,  histicated  computer  users.  This  feature 
monitors  the  transaction  rate  per  minute,  looking  for  out  of  profile 
work.  Tlte  event  Is  any  job  or  process.  The  measure  is  a  counter,  on 
a  session  length  cycle,  twenty  minute  periods.  The  update  is  average, 
so  the  profile  adjusts  the  moult  and  standard  deviation  automatically. 
The  model  is  deviation,  looking  for  significant  difference  from  the 
user's  norm.  The  weighting  is  low,  because  the  users  may  deviate 
from  their  routines  somewhat  on  occasion  and  we  are  not  interested  in 
minor  violations  of  this  limit,  if  a  trojan  horse  was  activated  invisibly, 
scanning  the  iiie  system  for  executables  which  it  might  attach  itself  to. 
the  transaction  rati*  would  soar  and  tin*  feature  warning  count  would 
go  high. 

Job  Mix,  Order  Entry.  Order  entry  at  Acme  is  a  dull  job.  The 
procedure  is  pretty  milch  the  same  all  tlte  time:  cpierv  the  inventory 
database  once  or  twice,  lill  out  the*  order  form  cmline,  and  post  an 
inventory  transfer  recpiest.  This  feature  looks  for  extreme*  variation  in 
the  routine*.  Tlte  events  unclei  serin  iny  are  tin*  queries  vc  t.-at**  t  lie  older 
entry  sequence.  The  measure  is  a  ratio,  on  a  (il)  minute  cycle,  ten 
minute  periods.  The  update  is  fixed,  because  we  know  tile*  pattern. 
Tin*  model  is  a  limit,  fixed  at  :i;  under  no  circumstances  should  the 
ratio  of  queries  to  orders  exceed  !)  over  a  ten  minute  period.  T  he 
weighting  is  medium,  if  an  intruder  found  his  way  into  the  system, 
and  began  doing  a  large  number  of  queries  into  the*  inventory  database, 
the  feature  warning  count  would  jump. 

3.0  Summary 

A  rule  base  for  ICE  is  determined  by  defining  the  system  security 
policy  and  finding  discriminating  features  in  user  work  patterns.  This 
process  is  crucial  to  successful  ICE  installation,  yet  remains  difficult 
and  subtle,  in  general  the  con  ten  l  of  the  audit  trail  will  affect  tin*  rule 
base. 

The  audit  trail  rail  lie  used  to  construct  and  update  a  distinc  tive 
profile  for  each  user,  characterizing  both  personal  work  habits  and 
tasks  normally  performed  on  the*  job.  Minor  deviation  front  a  work 


profile  Is  more  common  and  of  less  concern  than  a  combination  of 
violations.  Thu  more  stable  a  user’s  system  usage  pattern  is,  the  more 
likely  that  any  aberrance  from  this  pattern  is  evidence  of  intrusion  or 
abuse.  Users  in  a  production  environment  more  likely  to  exhibit  these 
consistent  and  stable  work  patterns. 

Tin*  audit  data  collected  on  most  computer  systems  is  not  useful  iu 
its  raw  form  for  manually  identifying  intrusions.  Existing  commercial 
audit  facilities  are  difficult  to  bypass,  but  are  a  possible  burden  for  the 
target  system;  expect  to  negotiate  with  the  system  administrator. 

The  audit  trail  features  described  above  cannot  be  derived  from  a 
quick  reading  of  the  audit  records.  The  audit  trail  must  be  distilled, 
summarized,  and  cross  referenced  to  derive  useful  information.  Locat¬ 
ing  features  which  .  st  discriminate  users  from  intruders  (or  proper 
use  from  abuse)  is  more  difficult,  still  (see  Usntjc:  Installation), 

4  A  Design:  PUMICE 

The  design  of  an  ICE  usage  monitor  is  demonstrated  through  pre¬ 
sentation  of  a  Proper  Usage  Monitor  for  Intrusion  Countermeasure 
Equipment,  or  PUMICE.  “Proper”  implies  compliance  to  system  pol¬ 
icy  and  user  historical  norms.  Design  objectives  for  PUMICE  are: 

Interactive  Usage  Analysis.  A  graphic  and  flexible  user  interface 
that  alerts  an  operator  to  suspicious  activity  and  facilitates  ef¬ 
fective  investigation.  A  summary  of  system  activity,  policy  vio¬ 
lation,  and  anomalous  user  work  patterns  coupled  with  a  flexible 
means  in  which  to  investigate  anomalous  activity  -  for  instance 
the  ability  to  graphically  compare  current  versus  profiled  activ- 
ity. 

Evolving  Profiles  and  Rulebase.  Continuous  aging  and  updating 
of  user  profiles  to  reflect  evolution  of  the  user  work  pattern.  As 
the  operator  learns  more  about  the  system  characteristics  and 
the  users'  habits,  tin*  rulebase  and  profile  templates  may  be  fine 
tuned. 

Minimal  Impact  on  Target.  No  modifications  to  the  target 

machine's  operating  system,  and  minimal  modifications  to  tar¬ 
get  machine's  auditing  mechanism.  There  should  he  little  per¬ 
formance  degradation  on  the  target  machine. 

Tin*  high  level  design  (Figure  I)  shows  subjects  as  ovals  and  ob¬ 
jects  as  boxes.  Audit  Formal  interprets  the  target  system  audit  trail 
and  enters  it  into  the  long  term  Audit  Database.  T  he  audit  records  are 
clunked  against  system  policy  by  Policy  Review  and  compared  with 
each  user's  profile  liv  Profile  Review,  Doth  review  processes  modify  the 
session  summaries  in  tlte  Summary  Database,  A  summary  is  created 
when  a  user  opens  a  session  and  is  updated  until  the  session  closes. 
Tin*  Profile  Updater  processes  each  normal  session  as  it  closes  and 
updates  that  owner’s  profile  in  the  Profile  Database.  Anomalous  ses¬ 
sions  must  be  manually  approved  before  the  profile  cult  be  updated. 
Extreme  deviant  behavior  may  activate  Countermeasure.  The  opera- 
l*u  ran  access  aJI  four  of  the  databases,  and  may  choose  to  initiate  (or 
inhibit  I  countermeasures. 

4.1  Audit  Data 

lit  using  existing  accounting  and  audit  facilities,  PUMICE  invokes  no 
changes  to  the  target  system,  because  these  facilities  are  well  estab¬ 
lished  (esp.-c ially  in  production  environments),  they  do  not  present 
a  formidable  political  hurdle  if  a  system  without  them  already  in¬ 
stalled  is  encountered.  Also,  beruuse  these  accounting  facilities  are 
old  technology,  they  have  settled  deep  into  the  operating  system,  and 
alt*  reasonably  robust  and  tamper  proof  in  their  data  collection. 

The  audit  trail  produced  by  the  target  system  will  not  be  just  as 
desired  for  our  analysis  engine.  The  Audit  Format  process  transforms 
the  raw  audit  trail  to  a  more  suitable  formut.  Performing  this  work 
on  PUMICE  is  more  secure  (see  Hardware  Jleqmnmrnls.),  lessens  the 
impact  on  the  target,  and  allows  the  monitor  to  he  installed  for  various 
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machine's  with  minor  software'  modification.  Sometimes  an  enhance¬ 
ment  of  the  audit  trail  may  he  iu  order.  On  some  IBM  systems,  the 
audit  records  are  associated  with  a  control  job  instead  of  a  user;  the 
Audit  Format  could  associate  job  IDs  with  user  IDs  in  the  formatted 
audit  trail.  The  information  available  in  the  audit  trail  will  of  course 
afreet  the  nature  of  the  rule  base. 

4.2  Hardware  Requirements 

PUMICE  is  designed  to  run  on  a  workstation  class  machine  with  high 
resolution  graphics,  a  mouse,  and  windowing  support.  These*  are  re¬ 
quirements  for  this  particular  design,  not  ICE  or  this  approach  in 
general.  The  use  of  PUMICE  as  an  investigative  tool  is  greatly  en¬ 
hanced  by  a  strong  graphical  interface.  The  hardware  should  have 
enough  power  to  perform  most  or  all  of  the  analysis  in  real  time  for 
the  best  countermeasure  capability.  By  running  the  security  monitor 
on  a  separate  processing  platform,  security  is  enhanced  and  the  target 
system  is  not  burdened,  PUMICE  mutt  have  a  solid  communications 
channel  to  the  target  system,  since  the  analysis  is  only  as  strong  as 
the  audit  trail. 

4.3  Database 

The  database  requirements  differ  substantially  In  two  phases,  system 
analytis/initallatlon  and  monitor  operation.  During  system  analysis  a 
large  audit  trail  database  is  surveyed  for  usage  patterns  whidi  discrim¬ 
inate  between  proper  usage  and  abuse.  Possible  features  which  show  a 
small  variance  over  time  are  entered  into  the  rule  base,  This  phase  is 
facilitated  by  the  high  level  database  query  language  SQL.  During  the 
operational  phase,  processing  proceeds  at  a  much  lower  level.  Com- 
putational  overhead  Inhibits  use  of  database  mechanisms  and  puts  a 
high  premium  on  usage  summaries  and  simple  indexing  for  retrieval 
of  related  records,  Several  database  packages  support  both  high  level 
analysis  and  high  speed  indexed  access  to  the  same  database  records. 
For  performance  gains,  the  analysis  engine  may  be  Implemented  in 


more  aerodynamic  access  method  code  instead  of  at  the  traditional 
SQL  programming  level  (thus  escaping  all  the  requisite  baggage  of  a 
full  DBMS). 

4.4  Analysis  Engine 

The  analysis  engine  accesses  the  DBMS  at  a  low  level  and  checks  cur¬ 
rent  activity  records  against  limits  (absolute  as  from  policy  statement, 
or  derived  from  the  profile),  Current  user  activity  Is  compared  sta¬ 
tistically  against  the  users’  respective  profiles  and  any  deviations  are 
reported  to  the  PUMICE  operator  for  review.  The  analysis  engine 
updates  profiles  as  high  water  mark,  average,  or  deviation  from  the 
mean.  System  behavior  is  kept  on  a  site,  group,  and  user  specific  ba¬ 
sis.  The  profiling  must  be  initialized  by  running  in  a  learning  mode 
over  an  appropriate  quantity  of  data.  Now  users  to  the  system  need 
to  be  given  a  generic  profile  from  users  with  similar  job  responsibili¬ 
ties,  and  watched  closely  as  their  profiles  harden.  User  sessions  and 
histograms  are  used  as  tiio  basis  for  counts  and  percentages, 

4.5  PUMICE  Security  Precautions 

Although  it  is  presumed  that  at  most  sites  the  system  console  will  he 
physically  secured,  security  features  have  been  designed  into  PUMICE 
itself.  Each  operator  is  issued  a  unique  account  ami  password  that  is 
used  for  access  mediation  and  for  auditing  the  activity  of  the  oper¬ 
ators.  An  appointed  system  manager  periodically  icviows  operator 
activity.  Non-priviloged  accounts  are  dedicated  to  run  only  the  mon¬ 
itoring  software,  and  do  not  permit  access  to  sensitive  tiles  or  any 
other  workstation  resource.  When  an  operator  takes  a  break  from  ac¬ 
tive  monitoring,  he/slic  may  lock  the  console  screen  without  closing 
the  session.  This  locked  screen  displays  a  non-specific  dynamic  ind, 
cator  of  the  security  of  tire  target;  if  particularly  anomalous  activity 
occurs  on  the  target,  keyboard  bells  and  the  locked  screen  reflect  that 
the  immediate  attention  of  an  SSO  is  required.  An  SSO  must  re-enter 
his/her  password  to  unlock  the  console.  Locking  of  the  console  screen 
:Uso  occurs  automatically  if  the  keyboard/mousc  remain  idle  for  some 
configurable  number  of  minutes.  PUMICE  maintains  a  complete  audit 
trail  of  significant  activity  on  the  security  monitor  itself.  The  audit 
trail  includes  both  SSO  activity  and  frequent  posting  or  the  system 
and  display  status. 

4.9  User  Interface 

The  maimer  in  which  to  best  distill  information  on  hundreds  of  users 
over  thousands  of  audit  records  and  tens  of  features  to  one  console 
screen  is  directly  related  to  the  success  that  a  PUMICE  operator  has 
in  discriminating  anomalous  activity.  Effective  analysis  of  anomalous 
activity  for  intrusionary  intent  is  dependent  upon  evaluating  this  ac¬ 
tivity  against  the  assimilated  knowledge  of  what  is  truly  abnormal  for 
the  target  system. 

The  design  of  the  user  interface  must  direct  full  attention  to  ab¬ 
straction  of  information,  human  engineering  and  effective  visual  pre¬ 
sentation,  ease  of  use,  and  flexibility  to  meet  differing  environments. 
The  powerful  windowing  environment  afforded  by  current  workstation 
technology  is  essential  to  an  effective  console  screen  Interface.  The 
following  concepts  optimize  the  human  interface  so  that  the  SSO  may 
quickly  and  effectively  assess  the  security  status  of  the  host  machine: 

Abitraction  of  information.  PUMICE  may  be  viewed  as  an  audit 
reduction  tool,  which  implies  that  there  will  be  activity  flagged 
that  is  not  alarmingly  abnormal  and  which  is  not  evidence  of  an 
Intrusion.  Suspicious  activity  is  ordered  on  warning  count,  and 
site  specified  alarm  thresholds  enforced  so  as  not  to  completely 
inundate  the  SSO  with  a  console  screen  full  of  false  alarms. 

Direct  access  to  target  system  audit  trail.  If  an  SSO 
believes  that  a  user  does  represent  a  potential  intruder,  he/she 
Is  able  to  easily  examine  this  user’s  activity  in  detail  down  to  the 
transaction  level  (regardless  of  whether  PUMICE  believes  it  to 
be  suspicious). 
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Multiple  windows.  Separate  windows  permit  simultaneous  access 
to  system  status,  complaints  of  abnormal  activity,  and  results  of 
querying  the  database  for  investigative  information. 

Stockpiling  events  until  manual  release.  The  SSO  can  not  be 

expected  to  be  present  at  all  times  to  immediately  investigate 
flagged  activity.  PUMICE  displays  and  saves  all  suspicious  ac¬ 
tivity  until  the  SSO  directs  a  manual  release.  If  the  SSO  comes 
back  from  lunch,  hc/slie  should  be  able  to  glance  at  the  monitor 
console  and  quickly  assess  to  what  degree  the  system  has  been 
subjected  to  abnormal  activity.  Activity  (lagged  as  being  sus¬ 
picious  is  not  used  to  update  the  user's  profde  unless  tile  SSO 
manually  releases  it. 

User  flies.  A  description  of  eacli  user  including:  job  description,  de¬ 
partment,  phys.cal  description,  location,  phone  number,  man¬ 
ager,  etc.  is  available.  Tho  SSO  may  append  notations  charac¬ 
terizing  the  user's  usage  habits. 

Investigative  capability.  A  llcxible  means  in  which  to  graphically 
compare  current  versus  profiled  activity,  and  the  ability  to  issue 
manual  queries  against  tire  database  is  available. 

Online  help.  PUMICE  provides  access  to  localized  help  facilities 
from  within  each  window.  A  new  operator  should  require  only  a 
slioil  supervised  training  period  to  become  proficient. 

PUMICE’s  windows  are  designed  to  quickly  focus  the  operator's 
attention  to  the  most  suspicious  activity  on  the  target  without  dis¬ 
tracting  the  operator  witli  details  about  normal  or  only  slightly  "ill  of 
profile  activity.  The  windows  use  screen  layout,  color,  and  highlight¬ 
ing  to  display  information  in  a  quickly  comprehensible  form.  Activity 
considered  potentially  serious  enough  to  present  u  threat  of  system 
compromise  is  energetically  highlighted  to  alert  the  operator  to  take 
immediate  action  and  hopefully  confront  the  user  in  question  while  still 
in  the  act  or  at  least  the  facility.  If  tin*  operator  requires  more  infor¬ 
mation  about  a  session  Hugged  as  demonstrating  intnisionary  activity, 
elements  in  tin1  windows  may  be  expanded  by  clicking  on  them  with 
tlie  workstation  mouse.  l  ent  lire  weighting  and  system  variables  may 
be  configured  to  meet  the  requirements  id  a  particular  installation. 

Operations  are  separated  into  a  number  of  windows  that  are  ini 
liaied  by  clicking  a  mouse  on  the  appropriately  labeled  button  of  a 
main  option  window.  PUMICE  may  be  considered  to  have  two  basic 
Inodes:  a  monitoring  mode  that  displays  status  and  security  relevant 
in  I'm  mat  ion  generated  by  current  activity  on  the  target  system,  and 
all  investigative  mode  for  when  the  SSO  requires  additional  informa¬ 
tion  from  the  impel  ot  from  the  audit  DBMS  in  order  to  investigate 
di'iowred  deviant  behavior.  Any  combination  of  these  windows  may 
be  opened  in  tlic  console  at  one  time  and  positioned  or  overlapped  as 
the  SSO  di-sites. 

4.(1. 1  Monitoring  Windows 

The  Security  Summary.  pontine  drill.  Selected  Session,  and  User  Data 
windows  of  this  mode  are  closely  tied  to  each  other  [figure  2).  When 
a  cell  on  the  Row  column  of  the  Security  Summary  window  is  mouse 
clicked,  the  related  session  row  is  highlighted  in  this  window,  as  well  as 
the  matching  column  of  the  feature  Crid  window.  A  summary  ol  the 
features  that  have  le'en  Haggl’d  for  the  selected  session  is  summarized 
in  a  Selected  Session  window,  and  information  on  the  owner  of  that 
session  is  displayed  in  a  User  Data  window. 

Security  Summary.  This  window  displays  an  ordered  list  of  ses¬ 
sions  that  are  Hugged  as  diverging  from  their  owners'  respective  pro- 
file:..  Sessions  are  flagged  as  suspicious  and  displayed  in  this  window 
when  the  session  count,  total  count,  or  any  individual  feature  count 
exceed  the  threshold  established  by  the  system  administrator. 

The  first  field  of  each  row  displays  an  index  number  for  that  session. 
The  second  and  third  Helds  display  the  session  II)  and  how  long  that 
session  lias  been  closed,  or  that  the  session  is  still  active.  The  fourth 


utd  fifth  fields  display  the  warning  counts  accumulated  for  that  session 
and  for  the  owner  over  all  sessions.  The  sixth  field  displays  an  interest 
value  (Note)  manually  tagged  to  the  owner  of  tho  session.  The  seventh 
field  gives  the  ranking  of  that  session  over  all  current  flagged  sessions 
based  on  the  session  warning  count.  The  Security  Summary  window 
is  normally  updated  every  10  seconds,  but  this  value  may  be  adjusted 
by  the  administrator.  The  screen  may  be  locked  during  investigation 
to  prevent  reordering  of  the  display. 

Ordering  of  the  Security  Summary  may  be  based  on  session  warn¬ 
ing  count,  total  warning  count,  session  name  (alphabetical),  imposed 
interest  level,  or  time  of  last  warning  count  update.  This  window  is 
normally  configured  to  order  the  flagged  session  rows  on  session  warn¬ 
ing  count,  and  may  be  scrolled  up  and  down  using  the  workstation 
mouse  or  keyboard,  The  ordering  of  the  session  list  may  be  changed 
by  clicking  on  any  of  the  middle  fi .e  column  headings  to  cause  reorder¬ 
ing  on  that  respective  field  (o.g.,  clicking  on  Session  Status  causes  the 
sessions  to  be  ordered  on  time  of  last  warning  count  update).  The 
ordering  chosen  is  signified  by  highlighting  of  the  respective  column 
heading.  Clicking  on  thr  Split  button  in  this  window  splits  the  twenty 
row  list  into  two  ten  row  lists,  eacli  with  their  own  scroll  bar  mecha¬ 
nisms.  Initially  both  new  lists  are  exactly  the  same,  displaying  the  top 
ten  rows  of  the  original  twenty  row  list  ordered  in  the  same  manner. 
Clicking  on  a  column  heading  now,  however,  only  affects  the  top  list  of 
ten  sessions.  Any  pair  of  orderings  is  possible  by  choosing  an  ordering 
for  the  entire  list,  splitting,  and  then  choosing  a  new  ordering  for  the 
top  half. 

The  PUMICE  operator  may  investigate  any  flagged  session,  Inti 
the  row  in  this  window  and  the  session  data  destined  for  the  Profile 
Updater  may  not  be  released  until  that  session  is  closed  by  the  owner. 
A  closed  session  may  be  released  by  clicking  on  the  (font  cell  of  a  session, 
in  releasing  a  session,  the  operator  will  have  the  opportunity  to  tag 
the  owner  with  tin  interest  value  ami  attach  comments  to  his  lecord. 
Subsequent  sessions  by  users  with  non-zero  interest,  values  will  always 
lie  (lagged  regardless  of  whether  they  fall  outside  of  profile  or  policy 
rules.  This  mechanism  allows  for  Increased  monitoring  of  users  who 
are  new  or  who  are  thought  to  present  ait  increased  risk  for  external 
reasons.  If  the  operator  believes  that  the  session  reflects  an  intrusion 
attempt  (particularly  a  masquerade),  or  if  the  session  is  Verified  to  he 
atypical  yet  valid,  the  operator  will  not  release  the  session  data  to  the 
Profile  Updater  so  ns  not  to  skew  the  user's  profile. 

Feature  Grid.  This  window  is  a  matrix  displaying  fiaturis  down 
the  left  side  and  sessions  displayed  in  the  Security  Summary  window 
across  the  top.  It  consists  of  a  gritl  made  up  of  colored  cells  laiieled 
with  warning  cotitil  values  for  each  feat  lire  of  t  he  flagged  sessions.  The 
higher  the  feature  warning  count,  the  warmer  the  cell  is  painted.  Ses 
si.ias  that  have  been  selected  and  highlighted  in  the  Security  Summary 
window  are  also  highlighted  in  this  window.  Clicking  on  a  feature  cell 
in  lids  wind,  opens  a  siihwiudow  containing  the  results  of  a  query 
to  the  11111111111X1'  for  a  summary  of  the  transact  inns  in  this  session  that 
increased  thut  feature's  warning  count. 

Selected  Session.  This  window  summarizes  the  flagged  features  of 
a  session  highlighted  in  the  Security  Summary  and  Feature  Grid  win¬ 
dows.  Eacli  feature  listed  specifies  Lite  last  time  that  it  caused  an 
increase  in  that  session's  warning  count  due  to  transactions  found  to 
lie  out  of  profile  by  this  feature.  This  provides  immediate  information 
on  when  iiitrusiouary  activity  last  occurred. 

User  Data.  The  User  Data  window  displays  general  information 
about  tile  owner  of  the  currently  selected  suasion.  This  information 
includes  such  items  as  name,  office  location,  phone  number,  manager, 
anil  authentication  data.  This  window  might  even  display  a  digitized 
picture  of  the  user’s  face. 

Nota  Bene.  This  window  acts  as  a  warning  window  of  activity  that 
clearly  violates  established  limits,  either  from  system  security  policy 
or  from  tho  user  work  profiles.  Explanatory  text  is  printed  to  this 
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Killin'  *J:  Sample  Monitoring  Screen 


window  i  homologically.  l‘p<%n  H’vn-w  t In-  operator  ran  send  mdividu.d 
nni.i  I  >i’ti  i*  items  to  In-  ,ur}ii\ni  It  should  be  fairly  ran*  that  not  a  him- 
ii«’»ii-  ,»r«‘  di*a ,  ini!  a  m  lulling  mechanism  a.v-oir<\s  that  .ill  r.tn 
Im-  M.wd. 


I » v  iis«*iID,  warning  muni.  and  leaiiue.  Highly  specific  individualized 
ijii»iit*s  into  tin*  dutubii.se  may  also  be  issued  louii  tills  window  1  liis 
window  is  noli  graphical  anil  moic  uppiopi  ialr  lor  sin  li  i  oriipurr-otis 
•is  lei  initial  Ills  against  a  s  ]>r« >i i !<■ .  ainl  I'M  sequence*,. 


4.8.2  Investigative  Window* 

1’ jm »n  ilisoivci y  <>T  anomalous  u< » i vitv.  tin*  System  Se*  itrity  Ollicer  uses 
ihi'-f  windows  to  i n v estigat e  (I  iguro  Ml. 

Cirnphual  Display.  ITMUT.  supports  tin*  construction  of  gruphi 
i  .i 1 1 1 iniparisniis  between  current  activity  vs.  |>r«»lil«**l  norms,  bar  i*r;i|>li 
display*.  of  Deviation  [rat tiros.  i*r  stup  chart  histograms  of  l  imit  fen- 
t  it  M-s  mn  It  as  iiumbei  of  <  tan  sac  t  ions  per  minute.  Specifications  lor 
ditli'M-iit  giaphs  may  bo  diawn  on  top  of  rock  other  ami  color  coded. 

I  ho  following  an*  possible  graphs  for  a  feature:  ovor  tin*  user's 
cii 1 1 i-til  s'ssimi.  ovi-r  a  recent  or  lung  term  profile  ol  that  same  iisit. 
iiM-t  that  user  s  groups  piolib1.  over  ui»»tl»«*r  nwr  '*  current  session  or 
pmlile.  Any  of  these  might  be  compared  against  each  other  or  the 
I'imu,  on  i  i  j«ht  be  i  oniparei!  against  a  not  hot  similar  feature. 

Database  Query,  litis  window  permits  direct  interface  to  the 
1'iflMS.  ('aimed  queries  are  provided  for  expected  common  requests 
for  analysis  ol  past  system  usage  These  include  displaying  a  user's 
[imfilc  vs.  current  session  parameters,  displaying;  all  ai.dit  records  ol 
a  user  from  soiii«»  starling  time,  and  displaying  reported  anomalies 


Terminal  Fimilation.  I'ltis  window  allows  an  opet.iioi  to  open  a 
session  onto  the  target  machine  from  the  1*1  MM  I.  console  Investiga¬ 
tion  and  necessary  immediate  ad  ion  to  preven.  damaging  intrwsionnn 
.u  tility  may  be  made  directly  from  a  (privileged)  account  «ut  the  tar 
g*'t. 

4.0.3  Other  Window* 

System  Administration.  This  window  per  mi  Is  tin*  1*1  Mil  i.  ad 
ministrator  to  configure  intrusion  threshold  values,  the  time  between 
si  lei'h  updates  of  the  Security  Summary  and  Feature  (»rid  windows 
length  of  idle  time  before  the  console  is  locked,  update  times  ol  lea 
lures,  transactions  that  will  always  be  (lagged  m.  possible  security 
hazards,  specifying  users  whose  sessions  will  then  always  requin*  man¬ 
ual  release  regardless  of  their  accumulated  warning  couni,  fields  to 
be  masked  in  the  audit  records  coming  from  the  target  machine  that 
have  no  applu.  Uty  to  this  target  machine,  the  number  of  raw  audit 
data  records  tha!  .ire  to  be  accumulated  before  records  are  copied  to 
archive,  and  initialization  profiles.  Database  maiiitenatice  tasks  an* 
also  performed  using  this  window.  Note  that  the  Fl'MK  F  admin 
i.strator  has  control  over  the  functionality  of  tin*  security  monitor:  it 
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Figure  Sample  Investigative  Screen 


may  be  desirable  to  separate  the  operator  and  administrator  jobs  at 
some  sites. 

Memo  and  Report.  This  window  supports  iho  informal  noting  of 
exported  future  deviant  behavior  as  foretold  by  the  user  { "I'll  be  work¬ 
ing  oi'ir  tin  weekend.'*)  or  circumstance  (“(imnp  X  will  l*  rrrhnnying 
office  spare  will:  droup  V.  so  rj-jurt  mtnnj  It  rminal  ids  In  hr  Jlatjytd 
as  abnovmal  for  members  of  these  groups").  This  window  also  sup¬ 
ports  the  more  formalized  reporting  of  witnessed  abnormal  behavior 
or  the  status  of  ongoing  investigations  from  one  shift's  SSO  to  the 
next,  or  external  information  (" Employee  A.  lF«/cr*  rvnigntd  titul  will 
Icuir.  (it  the  end  of  this  week").  It  is  expected  this  latter  reporting  has 
representative  usage  standards  in  the  t  raditional  facilities  guard  arena. 

Status,  The  Status  window  provides  general  operational  informa¬ 
tion  about  PU MICK  and  the  target  system  and  is  designed  to  display 
information  that  is  not  constantly  required  for  the  security  functions. 
This  reduces  the  clutter  and  optimizes  the  performance  of  the  other  se¬ 
curity  monitoring  windows.  The  Status  window  is  normally  examined 
when  the  operator  returns  from  an  absence  and  wants  to  check  that 
both  PUMIOK  and  the  target  system  have  been  operating  without 
problems. 

Information  displayed  in  the  Status  window  includes  the  date  and 
time  that  the  security  monitor  became  operational,  the  lime  thni  ihe 
last  console  activity  occurred  (other  than  activity  within  this  window). 


and  the  time  that  a  Status  window  was  last  invoked.  Si utistics  mi 
l  lie  total  number  of  audit  records  received.  I  lie  total  number  of  audit 
records  rejected  (because  of  line  noise  or  encryption  problems),  and 
the  total  number  of  audit  records  that  have  been  processed,  and  the 
number  of  audit  records  received,  rejected,  and  processed  since  the 
last  time  a  Status  window  was  opened  are  displayed.  The  window 
also  displays  information  on  the  target  machine,  operating  system, 
and  particular  configuration,  and  how  long  the  target  system  has  been 
operational. 

5  Usage 

This  section  describes  how  to  use  a  security  monitor  like  PI' MKT! 
once  it  is  fully  implemented  and  connected  to  a  live  target.  A  version 
of  this  intrusion  countermeasure  equipment  may  be  tailored  In  a  wide 
range  of  targets  if  an  appropriate  rulebasc*  is  constructed.  We  envision 
KIM  applications  for  Unix  development  environments  and  IBM  main¬ 
frame  MIS  and  dedicated  airline  reservation  systems.  K'K  is  even  an 
appropriate  tool  to  monitor  the  security  of  a  network:  with  the  nar¬ 
rowed  functionality  and  more  tightly  constrained  usage  standards  of  a 
nei work,  the  profiling  would  be  simpler  and  more  reliable. 

5.1  Installation 

Installing  PL’MKJK  requires  establishing  an  initial  rule  base,  formaliz¬ 
ing  .->vstem  policy,  entering  system  data,  collecting  initial  profile  in  for* 
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mation,  setting  thresholds,  and  defining  generic  profiles  by  job  descrip¬ 
tion  and  group.  The  trail  from  a  appropriate  period  of  auditing  of 
the  target  system  will  need  to  be  run  through  PUMICE  to  be  learned. 
Additional  tuning  using  SQL  will  be  required  to  customize  PUMICE's 
understanding  of  what  is  desired  to  lie  considered  normal  for  the  tar¬ 
get. 

The  initial  installation  should  not  be  expected  to  lit  perfectly  with 
tiie  target  system  and  user  base.  False  alarms  are  normal  until  adjust¬ 
ments,  botli  manual  and  automatic,  are  well  underway.  Features  with 
no  alarms  should  be  reviewed,  even  if  expected  to  be  good  discrimina¬ 
tors,  as  the  limits  may  he  set  too  high  for  appropriate  triggers. 

The  security  monitor  will  increase  in  effectiveness  the  longer  that 
it  is  operational  because  the  user  and  command  profiles  develop.  The 
local  system  security  officer  also  continues  to  gain  experience  and  be¬ 
come  more  proficient  at  the  “art”  of  distinguishing  innocuous  abno.  mal 
system  activity  from  truly  offensive  activity  for  this  site.  The  oxpe- 
rienre  111-  SSO’s  gain  from  their  investigations  will  gradually  become 
embedded  in  the  system  policy  atul  profile  templates  as  the  rulehase 
is  fine  tuned.  Training  of  now  operators  to  the  nuances  of  I’ll  MICE 
and  site  specifics  is  important. 

5.2  Operation 

ICE  should  be  expected  to  change  and  adapt  as  the  targeted  system 
and  the  activity  on  it  changes.  The  initial  rule  base  and  thresholds 
should  also  be  expected  to  develop  and  mature  as  the  administrator 
gains  experience  with  the  user  base  and  job  mix  on  the  target  system. 

Intrusion  attempts  may  progress  slowly  over  months  of  activity. 
The  bookkeeping  of  separate  events  of  deviant  behavior  in  the  Memo 
and  lieporl  Window  may  well  prove  valuable  as  an  evidence  gathering 
tool  and  as  an  aid  to  subsequent  legal  action. 

5.3  Vulnerabilities 

The  PUMICE  operator  must  be  well  versed  ill  the  vulnerabilities  inher¬ 
ent  to  tiie  adaptive  user  work  profile  approach  and  the  dependence  on 
the  integrity  of  the  target’s  audit  data.  Weak  profiles  allow  too  much 
latitude  for  the  user  work  patterns.  In  addition  to  attentive  Installa¬ 
tion  of  limits  and  thresholds,  the  SSO  must  be  cognizant  of  how  the 
profiles  changeover  time.  The  investigative  windows  support  display 
of  the  profile  limits,  averages,  and  deviations.  Those  displays  should 
be  cross  checked  with  a  variety  of  users  to  detect  profiles  that  have 
worn  loose  over  time.  Individuals  who  must  have  a  loose  profile  due 
to  the  variety  of  their  work  should  be  watched  more  carefully  because 
their  accounts  are  more  vulnerable  to  intrusion  and  masquerade. 

The  sophistication  of  an  intruder  is  of  course  a  major  factor  in  the 
probable  success  of  an  attempted  intrusion.  The  following  ordering 
may  be  made  on  increasing  potential  that  an  intruder  ran  keep  within 
the  profile  associated  with  an  account:  familiarity  with  system,  fa¬ 
miliarity  with  particular  installation,  familiarity  with  particular  user 
account,  familiarity  with  particular  usage  pattern. 

The  central  concept  of  our  approacli  to  audit  trail  analysis  is  that 
intrusion  and  insider  abuse  look  different  than  established  legitimate 
ese.  This  admittedly  will  not  be  the  ease  for  oil  incidents  of  intrusion  or 
abuse.  Our  experience  indicates  that  artful  development  of  system  and 
user  profiles  produces  a  security  monitor  applicable  to  a  broad  range 
of  systems,  detecting  many  different  kinds  of  misuse  or  inlrusionary 
attacks.  Detection  of  intruders  is  more  certain  on  machines  with  a 
stable  and  consistent  user  base. 

5.4  Countermeasure  Capability 

When  ICE  discovers  anomalous  activity  it  may  be  instructed  to  re¬ 
spond  with  different  levels  or  autonomy.  We  have  presented  PUMICE 
„s  foremost  an  investigative  tool  that  first  alerts  the  SSO  to  sessions 
wi  th  summaries  of  anomalous  activity  and  then  provides  him/her  with 
the  tools  (or  further  investigation.  PUMICE  is  not  designed  to  nor¬ 
mally  run  unattended  with  expert  system  software  making  Orwellian 
decisions  about  proper  usage.  Our  approach  does  not  assume  that 


anomalous  activity  will  always  be  understood  entirely  from  data  avail¬ 
able  on  the  target  system.  We  believe  that  external  verification  such 
as  phone  calls  to  the  offenders  (“George,  is  that  you  working  late  f"), 
their  managers  (“Has  Jane  been  assigned  work  on  Project  X?"),  etc. 
will  be  standard  procedure. 

Nevertheless,  many  sites  may  desire  ICE  with  the  capability  to 
take  action  on  its  own  if  system  activity  attains  an  overwhelming  level 
of  deviance  and  there  is  no  human  authority  available.  If  ICE  runs 
unattended  at  night  it  may  be  instructed  to  take  action  to  prevent 
system  compromise  while  attempting  to  alert  off-site  personnel.  The 
following  is  a  list  of  possible  responses: 

•  Challenge  the  user  to  confirm  identity. 

•  Slow  system  response. 

•  Pretend  to  execute  commands. 

•  Lock  the  account. 

•  Lock  the  entire  system. 

5.5  Privacy 

PUMICE  is  bound  to  raise  privacy  issues  especially  if  users  learn  of  the 
active  profiling.  Privacy  is  an  especially  valid  concern  when  macro¬ 
scopic  conclusions  about  users  become  readily  apparent  (“J.  lfiafra 
isn’t  as  fast  a  worker  because  lie  posts  70%  fewer  transactions  than 
II.  Rollins.”).  A  possible  solution  to  this  is  to  map  usernames  to 
pseudonyms  up  until  mirusionary  activity  forces  unveiling.  Legalities 
may  i>o  addressed  by  having  users  sign  consent  forms  when  they  apply 
for  the  account. 

6  Related  Work 

Auditing  computer  systems  and  reviewing  the  resulting  trails  has  a 
well  established  liislory  -  though  primarily  for  the  purpose  of  account¬ 
ing  and  job  charging  purposes,  and  generally  by  manual  means.  In  the 
past  year,  interest  in  intrusion  detection  has  increased  greatly  with  a 
number  of  separate  efforts  being  funded.  In  March,  1988,  S1U  In¬ 
ternational  facilitated  round  table  discussion  between  these  efforts  by 
hasting  a  workshop:  there  was  a  healthy  exchange  of  ideas  and  further 
workshops  are  scheduled. 

Sytek  Automated  Audit  Analysis  This  nroject  was  conducted 
in  1984-5  and  was  funded  by  the  Space  mid  Nav  il  Warfare  Command. 
It  used  audit  data  collected  at  the  Call  level  of  a  research  environment 
UNIX  machine.  Sytek’s  research  established  the  legitimacy  of  profil¬ 
ing  user  work  patterns  constructed  from  simple  and  readily  collectible 
audit  data.  It  demonstrated  the  ability  to  discriminate  between  nor¬ 
mal  and  abnormal  system  usage[6](7][8].  This  project  also  showed  the 
utility  of  using  database  tools  for  band  analysis,  prototyping,  and  in- 
vestignlioii  of  suspicious  activity. 

A  set  of  features  was  defined,  with  each  feature,  made  up  of  one  or  a 
combination  of  audit  data  parameters,  describing  an  aspect  of  system 
usage.  An  Automated  Audit  Analysis  tool  was  developed  using  an 
Ingres  DBMS  to  evaluate  the  viability  of  user  profiling  and  to  choose 
tiie  feature  set.  Hard  ranges  from  a  “learning  period”  were  used  instead 
of  ongoing  profile  updating  and  statistical  analysis.  A  set  of  intrusion 
scenarios  was  developed  and  performed  on  the  audited  machine,  and 
the  resulting  data  from  the  simulated  intrusion  attempts  examined. 

SRI  Real-Time  Intrusion  Detection  Sill’s  Intrusion  Detection 
Expert  System  effort  showed  the  practicality  of  audit  trail  analysis  per¬ 
formed  in  real  time  on  a  separate,  dedicated  computing  platform (5] [9], 
Modifying  a  TOPS-20  operating  system  to  collect  audit  data,  the  SRI 
implementation  examined  three  features:  source  terminal  location, 
length  of  a  user’s  session,  and  number  of  sessions  in  each  of  three  work 
shifts,  and  displayed  the  amount  of  anomalous  activity  system  wide. 
Analysis  and  reporting  is  organized  by  feature  rather  than  by  user. 
Their  results  show  that  much  can  be  gained  from  modest  data  collec¬ 
tion  efforts.  The  pffort  foiled  a  graphical  interface  to  lie  an  effective 
means  of  highlighting  intrusions. 
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Tracor  Haystack  Tracer  Applied  Sciences,  Inc.  is  developing  an 
audit  trail  analysis  system  called  Haystack  for  the  Air  Force  Crypto¬ 
logic  Support  Center  at  Kelly  Air  Force  Base,  Audit  trail  volume  is 
about  one  million  events  per  week  generated  by  Sperry  1100/60  main¬ 
frames  running  1972  vintage  operating  systems.  Haystack  processes 
audit  trail  events  using  statistical  measures  and  pattern  recognition, 
and  classifies  violations  with  deterministic  and  heuristic  rules. 

TRW  Discovery  TRW  Information  Services  Division  is  developing 
Discovery,  an  expert  system  based  design  for  “detective  and  preventive 
control  in  the  on-line  environment”[l  1],  TRW’s  goal  is  to  review  daily 
inquiry  activity  and  detect  unauthorized  inquiries  (out  of  some  400,000 
inquiries  per  day  from  a  base  of  120,000  customer  access  codes).  TRW 
has  found  Discovery  to  be  useful  for  non-security  purposes  such  as 
marketing  and  risk  analysis. 

NCSC  MIDAS  The  National  Computer  Security  Center  is  devel¬ 
oping  the  Multics  Intrusion  Detection  and  Alerting  System  (MiDAS) 
to  take  audit  data  from  a  Multics  system  and  compare  it  to  statisti¬ 
cal  user  profiles  maintained  in  LISP  structures.  Forty  heuristic  rules 
in  an  expert  system  shell  define  straight  limits,  expected  user  behav¬ 
ior,  expected  system-wide  behavior,  and  sensitive  command  sequences 
(similar  to  known  attacks).  MIDAS  runs  on  a  Symbolics  machine  using 
archived  audit  tapes. 

7  Conclusions 

A  standalone  security  monitor  with  adaptive  user  work  profiles  and 
policy  rules  is  a  powerful,  low-impact  means  for  addressing  the  throat 
of  intrusions  and  insider  abuse.  13v  using  existing  auditing  facilities, 
disruption  of  the  target  operating  system  is  avoided,  and  demands 
on  host  performance  and  resources  are  minimized.  Implementing  the 
ICE  on  a  separate  workstation  platform  provides  security  advantages 
as  the  audit  data  is  immediately  moved  off  of  the  target  system,  and 
the  monitor  software  is  isolated. 

The  more  narrowly  directed  the  activity  on  the  audited  system 
and  (lie  more  regulated  the  user  population,  the  more  stable  the  re¬ 
sulting  user  profiles  will  be;  a  production  environment  presents  less 
of  challenge  to  this  approach  than  does  a  research  environment.  So¬ 
phisticated  profiling  is  facilitated  by  an  information  rich  audit  trail, 
hut  even  very  limited  audit  trails  have  been  shown  to  be  successful  in 
flagging  intrusionary  work  patterns. 

The  intelligent  compounding  uf  feature  violations  offers  much  more 
information  than  the  respective  individual  component  elements.  The 
system’s  discriminatory  capability  will  improve  over  time  as  the  user 
profiles  mature.  Statistical  methods  to  mimic  the  evolution  of  a  user's 
work  profile  over  time  and  job  task  changes  are  necessary  for  adaptive 
profile  updating. 

Profiling  will  not  detect  a  break-ill  if  the  intruder  does  not  diverge 
noticeably  from  the  account’s  normal  pattern  of  system  usage,  or  if 
the  host  auditing  mechanism  is  subverted.  The  ICE  may  not  be  able 
to  discern  an  intrusion  that  is  performed  so  gradually  that  the  user’s 
work  pattern  is  never  divergent  enough  from  his/her  evolving  profile 
so  as  to  be  found  suspicious.  The  ICE  approach  will  not  be  able  to 
catch  an  insider  familiar  enough  with  normal  patterns  and  the  data 
elements  that  might  be  audited,  that  he/she  is  successful  in  avoiding 
exceeding  thresholds. 

The  design  presented  for  a  system  called  PUMICE  demonstrates 
the  summary  and  investigative  aspects  possible  with  this  approach. 
Techniques  to  best  condense  a  large  amount  of  analysis  to  abbreviated 
displays  of  anomalous  activity  that  are  held  for  later  review  are  aided 
by  the  window  and  graphical  capabilities  of  workstations.  Interactive 
tools  enable  Immediate  investigation  of  anomalous  activity.  Knowledge 
of  active  profiling  may  in  itself  act  as  a  deterrent. 


“Bobby  was  a  cowboy,  and  ice  was  the  nature  of  his  game, 
ice  from  ICE,  Intrusion  Countermeasure  Electronics...  Le¬ 
gitimate  programmers  never  see  the  walls  of  ice  they  work 
behind,  the  walls  of  shadow  that  screen  their  operations 
from  others,  from  industrial-espionage  artists  and  hustlers 
like  Bobby  Quine....  Bobby  was  a  cracksman,  a  burglar, 
casing  mankind’s  extended  electronic  nervous  system, 
rustling  data  and  credit  in  the  crowded  matrix,  mono¬ 
chrome  nonspace  where  the  only  stars  are  dense  concentra¬ 
tions  of  information,  and  high  above  it  all  burn  corporate 
galaxies  and  the  cold  spiral  arms  of  military  systems." 

-  Burning  Chrome,  William  Gibson 
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ABSTRACT 


In  performing  verification  tasks  on 
several  different  secure  software  projects, 
the  authors  have  been  required  to  address 
issues  concerning  software  quality,  size  and 
complexity.  Many  lessons  were  learned  in  the 
course  of  these  efforts  about  how  to 
efficiently  specify  and  verify  operational 
systems.  Additionally,  while  evaluating 
characteristics  of  both  programming  and 
specification  languages,  we  have  identified 
syntax  and  style  that  either  enhances  or 
obscures  security  analysis.  In  the  real  world 
of  large,  complex  systems  where  documentation 
often  provides  imperfect  inputs  to  the 
verification  process,  we  have  devised  methods 
for  clarifying  specification  style,  automating 
security  analysis,  and  improving  the 
communication  that  must  occur  between  designer 
and  verifier.  Much  of  this  work  has  focused 
on  the  use  of  Ada  both  as  a  PDL  and  as  an 
implementation  language. 

The  authors  used  the  COMPUSEC  Verifica¬ 
tion  Toolset  to  formally  verify  both  the 
Army/Air  Force  AN/GSC-40  Series  Command  Post 
Terminals,  and  the  Army's  Regency  Net  system 
(under  contract  to  Magnavox's  Northern 
Virginia  Systems  Division).  For  Regency  Net, 
this  involved  generation  >nd  then  analysis  of 
a  hierarchy  of  software  design  documentation 
consisting  of  three  tiers  of  specifications  as 
required  by  MIL-STD-490.  Ada  was  used  as  a 
program  design  language  at  both  the  B5  and  C5 
levels  of  specifications.  A  combination  of 
automated  and  manual  methods  were  used  to 
rigorously  analyze  Ada  PDL.  For  this  system, 
the  "distance"  between  the  verified  C5  and  the 
Pascal  implementation  code  was  very  small. 
This  leads  uo  to  believe  that  the  subset  of 
Ada  analyzed  in  this  C5  PDL  could  be  expanded 
into  one  sufficiently  rich  to  be  used  for 
verification  of  Ada  implementation  code.  We 
are  currently  pursuing  this  line  of  research 
under  Air  Force  Small  Business  Innovation 
Research  (SBIR)  contract  F19628-86-C-0203 . 

APPLICABILITY  of  AUTOMATED  VERIFICATION  TOOLS 

We  have  developed  a  methodology  for 
formal  verification  of  MLS  properties  based  on 
the  KDM  methodology  and  the  work  of  Richard 
Feiertag  [1].  Variations  of  this  methodology 
are  being  used  to  verify  both  the  an/gsc-40 
series  Command  Post  Terminals  and  Regency  Net 
to  achieve  levels  of  assurance  approaching 


those  described  at  the  A1  level  of  the 
Criteria  [2].  This  methodology  has  been 
applied  to  the  preliminary  design,  detailed 
design,  and  deployment  life-cycle  maintenance 
phases  of  system  development.  Several 
iterations  of  a  combination  of  automated  and 
manual  steps  were  used  to  find  logical 
inconsistencies  in  design  documents  at  each 
phase.  Extension  cf  this  methodology  to  cover 
both  MLS  and  proof-of-correctness  analysis  of 
either  Ada  PDL  or  source  code  is  currently 
under  development  [3], 


Verification  methodology  development  has 
been  an  evolutionary  process.  Automated 
portions  were  developed  in  an  attempt  to 
circumvent  both  human  and  resource  limitations 
while  meeting  project  deadlines.  Manual 
efforts  required  comprehensive  training  and 
were  best  applied  to  fails  analysis.  Both 
extensive  explanations  of  the  causes  of  failed 
proofs  as  well  as  justification  of  the  methods 
employed  ware  often  required  in  the  face  of  a 
skeptical  attitude  towards  the  worth  of  formal 
verification.  The  timeliness  and  relevance  of 
both  input  documentation  guidelines  and  output 
discrepancy/failure  reports  wnre  also  often  at 
issue.  Much  has  been  learned  in  the  process. 


We  believe  that  the  feedback  loop  between 
software  designer  and  verifier  must  be 
shortened  so  that  more  iterations  of  the 
verification  process  can  economically  occur  at 
each  stage  of  the  software  life-cycle.  It  is 
expected  that  responses  to  security  feedback 
reports  will  act  to  increase  software  quality 
assurance  whilo  reducing  cycles  of  formula 
generation  and  therefore  ultimately  reducing 
the  number  of  failed  proofs.  Once  fails  have 
been  located,  it  is  the  job  of  fails  analysis 
to  then  quantify  the  bandwidth  of  the  channels 
discovered  and  determine  the  degree  of  risk 
vs.  the  cost  of  a  fix. 


Automated  tools  are  particularly  valuable 
when  they  allow  achievement  of  greater 
accuracy  and  throughput  than  is  possible  using 
manual  analysis.  We  utilize  automation  at  a 
variety  of  points  in  the  overall  verification 
process.  Descriptions  of  several  currently 
used  elements  of  our  verification  toolset 
follow: 
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VERIFICATION  TOOL  DESCRIPTIONS 

COMPUSEC-Enhanced  HDM.  The  HDM  tool  set  (also 
called  "old  HDM" )  was  originally  developed  by 
SRI  International.  Initially  intended  to 
structure  the  overall  software  development 
process,  it  has  found  a  specific  application 
in  MLS  security  analysis.  HDM  includes  the 
language  SPECIAL  (SPEClficatior.  and  Assertion 
Language) ,  a  theorem  prover,  and  the  MLS 
formula  generator  for  multilevel  security  [1). 
We  have  ported  HDM  from  the  Digital  Equipment 
Corporation's  TENEX  operation  system  to 
VAX/VMS.  We  also  modified  the  user  interface 
to  the  MLS  tool,  added  a  label  propagator,  and 
corrected  how  the  Verifier  counts  failed 
proofs. 

ATOS.  ATOS  (Ada-to-SPEClAL)  works  as  a 
security  cognizant  Ada  parser/trans.latcr .  In 
addition  to  translating  a  subset  of  MIL-STD- 
1815A  Ada  into  an  FTLS  (Formal  Top  Level 
Specification)  written  HDM's  specification 
language  SPECIAL,  ATOS  generates  valuable 
discrepancy  reports  that  provide  feedback 
relevant  to  software  quality  assurance. 
Problems  identified  include; 

•  Parsing  problems 

•  Undefined  subprograms 

•  Undefined  types 

•  Undeclared  variables 

•  Type  mismatches 

•  Formal  and  actual  parameter  mismatches 

•  Illegal  assignments  to  constants 

•  Missing  referenced  files 

ATOS  also  identifies  local  and  global 
scopes  of  data  items  in  preparation  for 
further  processing  by  the  Labeler  tool.  ATOS 
handles  security  ramifications  of  Ada's 
modularity:  The  constructs  "with"  and 

"separate"  are  addressed  in  a  consistent  way 
by  searching  both  current  and  configuration 
management  directories  for  the  referenced 
files.  Once  a  match  is  found,  it  is  then 
instantiated  into  the  correct  scope.  To 
account  for  capabilities  not  easily 
represented  in  Ada,  ATOS  recognizes 
annotations  in  the  Ada  PDL.  Annotations 
include  representations  of  the  data  items 
transported  in  low-level  procedures  and  the 
locations  of  referenced  files. 

BTOS.  BTOS  (Bubble-to-SPECIAL)  is  used  for 
data  flow  analysis  and  produces  FTLS  from  data 
flow  diagrams  [4].  Data  flow  diagrams  (DFDs) 
can  be  developed  from  the  top-level  PDI.  in 
order  to  show  the  definition  of  the  functional 
interfaces  of  the  system.  Given  DFDs  that 
reflect  all  information  flow  for  these 
interfaces  BTOS  identifies  the  following: 

•  The  shortest  path  between  two  nodes 

•  All  possible  paths  between  two  nodes 

•  Paths  between  two  nodes  that  contain 
labeling  conflicts 

Discrepancies  are  identified  as  they  occur, 
and  DFD  components  can  be  adjusted 
dynamically.  When  labsling  conflicts  occur, 
BTOS  examines  the  security  attributes  of  the 
entities  involved  and  either  relabels  them 
through  use  of  a  label  propagation  algorithm, 
or  shows  an  unresolvable  conflict.  If  only 
external  inputs  and  outputs  of  a  module  are 
given  labels,  the  setting  of  all  internal 
labels  to  the  system's  least-dominant  level 


followed  by  propagation  of  these  labels  across 
the  DFD  allows  BTOS  to  find  the  least-dominant 
conflict-free  set  of  labels  of  all  entities  in 
the  module  under  analysis. 

TAT.  TAT  (Trustedness  Analysis  Tool)  is  used 
to  determine  allocation  of  trust  in  a  secure 
system  design.  Given  an  input  of  formatted 
tables  representing  all  possible  paths  between 
components  in  the  system,  TAT  will  identify 
which  components  of  the  system  need  to  be 
trusted  with  respect  to  secrecy  and  integrity. 
The  formatted  tables  that  are  used  by  TAT  are 
consistent  with  the  Ada  PDL  and  reflect  all 
inter-component  flow  of  data  specified  in  the 
PDL.  TAT  performs  a  data  flow  analysis  of 
these  tables  that  includes  checking  of  inter- 
and  intra-component  I/O  consistency  as  well  as 
consistency  with  Data  Dictionaries.  TAT 
determines  which  design  modules  potentially 
violate  the  system  security  policy  and 
therefore  must  be  trusted  to  carry  out  their 
functionality  in  a  secure  manner.  Other 
modules  are  secure,  by  induction. 

Labeler.  The  Labeler  accepts  as  input  an 
unlabeled  SPECIAL  FTLS  and  local  and  global 
Data  Dictionaries,  and  produces  labeled  FTLS 
as  well  as  discrepancy  reports.  It  determines 
the  scope  of  data  items  and  assigns  correct 
labels  to  them  based  on  definitions  found  in 
the  local  and  global  dictionaries. 
Discrepancy  reports  identify  problems  with 
consistency  in  the  Data  Dictionary  itself,  as 
well  us  disconnects  between  the  Dictionary  and 
the  FTLS.  If  errors  of  omission  or  commission 
exist  between  records  and  their  components, 
the  Labeler  flags  these  cases  and  then 
relabels  record  components  according  to  rules 
which  preserve  the  meaning  of  the  security 
model.  The  Labeler  can  also  format  the  Data 
Dictionary  and  its  security  labels  into  a  file 
suitable  for  processing  by  the  TAT  tool. 

Labeler-Propagator.  We  added  a  propagator 
tool  to  HDM's  environment  for  use  in 
conjunction  with  HDM's  MLS  tool.  The 
Propagator  assigns  security  labels  to  data 
items  not  assigned  fixed  labels  in  such  a  way 
as  to  minimize  security  conflicts.  The 
Propagator  assigns  default  security  labels  to 
any  data  items  within  the  FTLS  which  were  not 
already  assigned  labels  by  the  Labeler.  It 
then  uses  a  data-dependency  recognition 
algorithm  and  a  property  violation  algorithm 
equivalent  to  those  implemented  by  Compusec- 
Enhanced  HDM  in  recognizing  potential  security 
violations.  The  Propagator  writes  a  new  Ftls 
file  in  which  all  data  items  have  been 
propagated.  It  also  reports  labeling 
conflicts  that  occur  any  time  data  flows 
between  data  items  with  incompatible  security 
labels.  Use  of  the  Propagator  has  proven  to 
be  quicker  and  more  accurate  than  previous 
efforts  using  manual  propagation. 

Splitter.  The  Splitter  has  enabled  us  to 
handle  the  formal  verification  of  a  large 
system  in  a  timely  manner.  If  an  FTLS  module 
is  too  large  to  be  processed  by  HDM  within 
system  memory  constraints,  it  must  r-  broken 
down  into  appropriate  subunits.  The  Splitter 
allows  verifier-defined  limits  to  be  put  on 
the  size  of  these  units  while  maintaining  an 
accurate  representation  of  the  original  large 
module.  The  Splitter  correctly  preserves 
scoping  and  interdependencies  and  produces  the 
following: 
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•  Hierarchical  Structure  -  This  shows  how 
the  module  is  split  and  enables  ease 

in  seeing  relationships  between  high  and 
low  level  procedures. 

•  Recursion  Identification  -  HDM's  MLS 
tools  do  not  accept  recursive  functions. 
Instances  requiring  manual  response  are 
identified. 

•  Smaller  SPECIAL  Files  -  Resulting  files 
are  not  only  more  manageable,  but  they 
remain  parseable. 

STOF.  The  Souree-to-Formulas  tool  provides  an 
integrated  verification  environment  that 
operates  on  Ada  code  or  PDL.  STOF  directly 
translates  code  or  PDL  into  provable  formulas. 
It  also  translates  security  policy  into  axioms 
and  rules.  The  security  policy  to  be  applied 
to  analyses  of  the  code  or  PDL  can  specify 
desired  system  behavior  with  ruspsct  to  either 
multilevel  security  or  correctness. 

Halfcllevel _ security  Concept.  STOF's 

verification  of  MLS  properties  is  based  on  use 
or  it.  security-cognizant  parser  in 
conjunction  with  a  labeling  mechanism.  The 
parser  extracts  type  and  scoping  information 
from  the  source  input  and  creates  unique  names 
that  are  formatted  in  its  parse  tree.  The 
parser  recognizes  subjects  and  objects  and 
performs  path  analysis  to  determine  the 
shortest  path  between  any  subject/ object 
pairs.  The  collaborating  labeling  mechanism 
allows  data  dictionary  information  to  be  added 
to  path  information.  The  data  dictionary  used 
supplies  all  fixed  security  labels.  Labels 
themselves  may  be  multi-attribute  and  of  a 
project-specific  format.  The  labeling 
mechanism  transcribes  the  fixed  labels  to  each 
instance  of  that  data  item  found  in  the  parse 
tree.  once  all  fixed  labels  have  been 
transcribed,  remaining  unlabeled  or  floating 
label  data  items  are  subjected  to  label 
propagation.  Propagation  is  a  multi-pass 
operation  that  attempts  to  find  the  least 
dominant  conflict-free  path  between  all 
subject/object  pairs.  The  number  of 
propagation  passes  corresponds  to  the  radius 
of  a  call  graph  of  the  system.  Unresolvable 


conflicts  are  flagged  as  potential  security 
violations. 

Pi oof-of-Correctness  Concept.  STOF's  handling 
of  proof-of-correotness  is  based  on  definition 
of  a  desired  transformation  that  can  be 
described  using  formal  notation.  Source  is 
analyzed  by  deriving  and  then  formally 
notating  its  properties.  Proofs  involve 
demonstrations  showing  tnat  valid  translations 
of  source  properties  imply  only  the  desired 
transformation . 


STOF  Components  and  User  Interface.  STOF  is 
currently  implemented  in  SUN/Ada  and  runs  on  a 
SUN  Microsystem  Model  3/60.  Inputs,  outputs, 
and  major  components  are  shown  in  Figure  l. 
Low-level  commands  to  STOF  treat  operations  as 
predicates  to  be  evaluated.  Although  a  PROLOG 
syntax  and  semantics  are  sufficient  to 
describe  all  operations,  a  visually-oriented, 
window-based  user  interface  is  under 
development  for  ease  of  use. 

SKainp.le  j - Star  Network  Simulator  (SNSl .  STOF 

has  been  tested  and  demonstrated  by  using  it 
to  verify  a  small  network  simulator  program. 
SNS  models  identical  terminals  as  an  array  of 
Ada  tasks  managed  by  a  terminal  controller 
that  is  a  single  Ada  task.  Terminal  tasks 
request  a  security  level  at  login.  From  this 
point  on,  the  terminal  controller  handles 
message  input  and  output  in  a  secure  fashion 
and  issues  an  audit  trail.  The  current  simple 
security  model  only  allows  terminals  at  the 
same  level  to  pass  messages.  A  known  security 
violation  exists  in  the  SNS  in  that  all 
message  passing  occurs  using  the  same 
routine  WRITE_WIRE.  The  "wire"  is  unprotected 
and  therefore  has  been  labeled  at  level  "1" 
(low).  When  SNS  handles  messages  at  level  "2" 
(high) ,  a  violation  occurs  because  messages 
are  sent  over  the  level  "1"  wire.  STOF 
discovers  and  reports  this  by  processing  input 
SNS  source  code  and  a  simple  data  dictionary. 
Figures  3-6  contains  fragments  from  SNS 
source  and  STOF  output  that  demonstrate 
discovery  of  this  security  violation. 


FIGURE  1.  STOF  Inputs,  Major  Components,  And  Outputs 
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--//  WRITEWIRE! 

--// 

--//  Writes  data  to  the  finiulittd  wiro,  in  *  real 
--//  application  this  routine  would  interfac-  to  a 
— //  low  level  output  routine. 

--// 

— //  MESSAGE  is  output  to  th*  DESTINATION  TERI  INAL 
—  //  win. 

— // 


procedure  WRITE  WIRE  ( 

“DESTINATION  TERMINAL  :  in  LONG  INTEGER  ; 
MESSAGE  :  in  SHORT_STRINQ  )  ifl  ' 

begin 

WIRE  ( DESTINAT 10 N_TE RHINAL )  t«  MESSAGE  • 
end  WRITE_WIRE  J 

STOF  PARSE  TREE! 


procedure  body(write_wire,nu.ll , 

t in ( ( d  e  b  tTnation _ termini 1 ) ,  name ( long  integer  J , null ) , 

in(  [  message  > ,  name (shortest ring )  .null)) . 


slat pm»nt (null, 

nanfluiri, a  rgs ( nane ( das t ina t ion_t ermine! ) ) ) 

:■  name ( massage ) ) ) , 


null » 


figure  3.  Ada  Source  and  STOF  Parse  Tree  for 
Procedure  WRITE  WIRE 


function  riNDACCESP  ( MESSAGE  :  in  SHORT  STRING] 

raturn  LONG_INTEOER  is 

RESULT  :  LONG_INTEOEP  j 
begin 

call  MESSAGE  <21  is 
whan  ' 1 '  »> 

RESULT  !■  ACCES5_0NE  j 
whan  ‘ 2 1  ■> 

RESULT  :*  ACCESS_TWO  ; 

whan  others  ■> 

RESULT  : «  NO_ACCES$  : 

and  cast  ; 

return  (RESULT)  J 

and  f IND__ACCE3S  i 

STOT  PARSE  TREE: 

f  unction_body  (  f  ind__accaia  ,  ( Ion g_lnteger , null ) , 

(  in  {  I  me  saiga ) . nameTshc rt_atr ingT, null ; 1  , 

( va  t  i abla^dac 1 1 { r a  suit ) , nana ( long_intager ) .null] J , 

statement (null , 

ca8c{name(Message,args{integer(2) ) )  , 

t 

( <  character (49)1, 

[ 

s tat  ament ( null , name ( renul t )  i»  nine ( acc r b s_ona } ) ) )  . 

(  (  character l 50 ) | , 

l 

■tatementlnull  ,naa«(  result )  i»  name  ( *ceii»_twci )  )  ] )  , 

( (other* 1 , 

[  r.  ta  t  ament  (nul  1  ,  name  l  result )  name  <  no_aece  «  s  ]  )  |  )  |  i  i  . 

statementinuil,  at  ur  n^s  t  at  ament  (  name { result  I ) H . 
null)  “ 

FIGURE  4.  Ada  Source  and  STOF  parse  Tree 
for  Procedure  FIND  ACCESS 


--//  PROCESS  SENDMES3AQE ! 

--// 

--//  Determines  if  *  wand  is  valid,  in  this  simple  iodel  only 
--//  terminal'  at  the  name  level  are  allowed  to  pass  messageu. 

--// 

procedure  PROv.iSS^SEND  MESSAGE  ( 

“  “  SOURCETEHMINAL  :  in  LONG  INTEGER; 

MESSAGE  :  in  SHCRT  STRINgT  in 
DESTtNATION_TERMINAL  :  LONG_I NTEOER  i 
begin 

DESTINAVIONJTERMJNAL  ! a  CHARACTER ’ POS  (MESSAGE  ( 2 ) >  - 

CHARACTER' POS  { ' 0  '  )  ; 

if  (DESTINATION  TERMINAL  <  MI N_TERMI NAL )  or 

( DEST I  NAT ION_Tt RHINAL  >  MAXJTERHINAL I  then 
PUT  LINE  (  "SeTveri  reads  bad“deatinat ion  addreaa"  a 
“loNQ_XNTEGER' XMAGE  ( DE9TX NAT ZCN_?CRM INAL)  fc 
"  from  terminal"  t 

LONO  INTEGER' IMAGE  (SOURCE  TERMINAL))  ; 

SEND^BAD  DESTINATION  MESSAGE  (SOURCE  TERMINAL)  ; 
alaif  (TERMINAL  ACCESS  (DESTINATION  TERMINAL)  ■ 

TERMINAL  ACCESS  { SOURCE  TERMINAL))  and 
(TERMINAL  ACCESS  (SOURCE  TERMINAL)  >  NO  ACCESS)  than 
SEND_FROM_H BADER  ( 30URCE_TERHI NAL , 

DKSTTnATION_TERHINAL)  ; 

--//  This  massage  is  okay  to  sand  to  the  destination 
terminal.  Server  put*  the  message  on  the  wire 

WRITE_Wiat  <  DE5TINATION_TtRMXHAL ,  MESSAGE)  ; 

- -//  server  notifies  the  destination  terminal  of  the 
--//  inconming  message  with  the  entry  point  “ race i ve_»e a  a  age " . 
--//  A  real  symtem  m»ght  use  handshake  lines,  or  other 
— //  aignala  here. 

TERMINALS  ( DEST1 NAT 1 0N_TE RHINAL  I  . RECE IVE_HESS AQC  ; 


else 

PUT_LINE  ( 

’'Server  t  Terminal M  fc 

LONG_I NTEGER ' IMAGE  ( SOURCE ^TERMINAL )  t 
“  ^“terminal"  a 

LONG_INTEOER' IMAGE  ( DESTXHATION^TERMINAL )  l 

"  sand  massage  raguast  denied  because  of  access  violation.'' 

) 

SEND_N0T_ALL0WED_HE3S AO  E  < 90URCETERHI NAL )  i 

and  lf“i  “ 

and  PROCESS  SEND  MESSAGE  ; 


FIGURE  5.  Ada  Source  for  Procedure  PROCESS  SEND  MESSAGE 


%  parse! 'demo. ada' ,X) . 

X  -  (null, 

procedure  body (demo, null , [ ] , 

[ 

cons tan t_decl( (min_terminal ) ,name( long_integer ),integer(0)!, 


More? 

no 

l  consult! ’demo_translations' ) . 
yes 

%  consult! 'demo__labelb' ) . 
yes 

l  propagate ( X) . 

Analyzing  flows  for:  [demo, controller, process_message) 
Analyzing  f?ows  for:  ( demo , controller , find_accesG ] 

Analyzing  flows  for:  [ demo , controller ,process^send_message 1 
Analyzing  flows  for:  [ demo , controller ,write_wlre ] 

Analyzing  flows  for:  [demo, controller j 
Analyzing  flows  for:  ( demo , terminal_task ] 

Analyzing  flows  for:  [demo] 

Pass:  1 


Get  label  for:  object ( message , (demo, controller ,write_wi re )) 2 
Get  label  for:  object! wire , (demo ]) 1 
Comparing:  message(2)  ->  wired; 

****  Unresolvable  conflict  ****  : 

message,  declared  in  [ demo, controller .write _wire ] ,  label  2  -> 
wire,  declared  in  [demo],  label  1 
Get  label  for:  object ( k l ,(]) 0 
Get  label  for:  object ( destination_terminal , 

(demo, controller , process  send_message ) ) 1 
Comparing:  kl(0)  ->  destination_terminal (T) 


Label  changes:  9 
Unresolved  :  1 
Pass:  2 


Label  changes:  3 
Unresolved  :  1 
Pass:  3 


Label  changes:  0 
Unresolved  :  1 

x  «  propagate_results( [ 

label~change(object(terminal, [demo,_send_bad_destination_message] ) ,1,2)  , 
label_change(object(destination  terminal, [demo,_send_f rom_header] ) ,1,2) , 
label_change( object! source_te rmlnal , [ demo ,_send  f romheader ) ) , 1 , 2 ) , 
label_change ( object! terminal , [ demo,_access_leveI_change_message ] ) , 1 , 2 ) , 


label_change( object ( my  terminal  number , [ demo , te rminal_task ] ) , 1 , 2 ) , 
label“change( object! terminal » [demo,  create_terminal ) ) , 1 , 2 ) , 
label_change(ohject(console, (!) ,0,2)7,  ~ 

l 

objectfmessage, Idemo, controller, write_wire) )  ->  objectlwire, [demo] ) ] ) 

More? 

no 

%  logout. 


FIGURE  6.  EXTRACTS  from  STOF  MLS  Analysis  of  SNS 
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CONCLUSIONS 


Secure  system  development  has  only 
recently  become  a  practical,  applied  science 
[5].  Two  major  categories  of  methodology 
enhancement  need  to  be  pursued:  1)  The 
semantics  and  logical  consequences  of  certain 
Ada  statements  with  respect  to  both  MLS  and 
proof-of-correctness  properties  must  be 
specified.  2}  Additional  automated 
verification  support  tools  that  shorten  the 
designer/verifier  feedback  loop  must  be 
developed.  Achievement  of  these  objectives 
will  result  in  the  means  to  both  quantify  and 
evaluate  the  level  of  assurance  of  operational 
software  development  projects  requiring  higher 
reliability  and  quality. 
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ABSTRACT 

This  paper  describes  a  suite  of  tools 
used  in  evaluating  software  for  security 
certification.  The  Lools  are  currently  being 
used  on  software  for  secure  Electronic  Funds 
Transfer,  but  could  be  applied  to  other  appli¬ 
cations  its  well. 


1.  Introduction 

One  of  the  valuable  services  provided  by  govern¬ 
ment  agencies  is  certification  of  commercial  products. 
Familiar  examples  include  the  rerlilicntions  of  food 
and  medicine  performed  by  the  Food  and  Drug 
Administration.  Tt>  support  the  need  for  secure  elec¬ 
tronic  funds  transfer  (EFT)  of  both  industry  ami  its 
own  bureaus,  the  U.S.  Treasury  Department  initiated 
a  program  for  certifying  EFT  equipment  |Ferr87, 
TfrnSli].  To  assist  in  this  elfort.  the  National  Bureau 
of  Standards  (N’liS)  hits  been  developing  source  code 
analysis  tools  to  assist  in  the  evaluation  of  software 
Used  in  EFT  eg  liptnent.  This  paper  describes  some  of 
tiie  tools  that  have  been  developed  and  work  that  is 
currently  in  progress. 

The  EFT  equipment  being  certified  provides 
A\:s|  Xti.tl  Message  Authentication  capability 
(A NS  1SCS|  and  ANSI  X0.17  Key  Management  functions 
[A.NSlH-1).  'The  equipment  typically  includes  a  secure 
microprocessor  and  u  chip  to  perform  eneryptio-,  using 
the  Data  Encryption  Standard  [NHS77].  Software 
controls  access  to  the  various  functions  through  either 
password  protection  or  magnetic  cards.  The  software 
is  usually  small,  approximately  1 .000  lines  of  source 
code. 

Commercial  developers  supplying  EFT  equipment 
to  the  Treasury  Department  are  required  to  develop 
it  according  to  specifications  given  in  [TrcaHOb].  The 
.specifications  mandate  security  features  recommended 
in  (NSASBj  and  include  requirements  to  aid  in 
verification  stlgg'slcd  by  |NBS81>],  One  job  of  the 
security  analyst  Is  to  review  the  source  code  to  ensure 
that  access  control  checks  are  performed  properly  and 
that  critical  data  are  not  acecssil.de  to  unauthorized 
users.  This  review  clearly  cannot  he  fully  automated; 


it  can  only  be  done  by  a  trained  analyst  who  takes 
the  time  to  understand  the  source  code.  Software 
tools  can  improve  the  process  by  helping  reveal  the 
structure  of  the  system  and  by  performing  certain 
mechanical  checks  on  syntax  and  control /data  How 
(e.g.  as  provided  by  lint  [Jolm78j).  UNIX*  tools  such 
as  Uni.  jjrcp  (BSD80|  and  nii'k  (Aho78j  arc  heavily 
used  in  the  evaluations,  hut  this  paper  will  present 
only  now  tools  that  have  been  developed  to  supple¬ 
ment  UNIX  utilities  and  other  commercially  available 
tools. 

1.1.  Prototype  Tools 

Thu  tools  described  in  this  paper  are  designed  to 
help  the  security  analyst  understand  the  system  being 
evaluated.  The  information  they  provide  could  tie 
gathered  without  tool  support,  but  to  do  so  would 
take  considerably  longer.  An  additional  advantage  is 
that  i  ‘ tools  provide  a  variety  of  views  of  the  sys¬ 
tem.  Documentation  is  expected  to  contain  much  of 
the  information,  but  one  goal  of  the  tool  suite  is  to 
assist,  in  cheeking  consistency  and  correctness  of  docu¬ 
mentation.  Many  of  the  functions  provided  by  tools 
described  in  this  paper  are  available  from  other  tools, 

The  paper  will  point  out  features  of  our  tools  that  are 
not  provided  by  ot  hors. 

The  tools  that  have  been  developed  arc  designed 
for  use  on  (•  source  code  (Kern78).  C  is  an  appropri¬ 
ate  target,  language  for  the  prototypes  because  0  is  a 
popular  language  for  micro-processor  applications. 
Most  of  the  source  code  for  the  EFT  equipment  is  C, 
although  various  assemblers  arc  used  as  well.  The 


*  UNIX  is  a  registered  trademark  of  AT&T 
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tools  are  written  in  C  and  aic  modular  so  that  it  is 
relatively  easy  to  modify  them  to  suppoit  other 
languages.  In  one  case  the  code  for  the  equipment 
being  evaluated  was  written  entirely  in  Z80  assembler 
and  the  parser  was  modified  in  an  afternoon  to  handle 
the  assembly  code. 

1.2.  Tool  Design 

Most  of  the  tools  follow  a  common  design,  shown 
In  Figure  1.  The  pre-processor  Is  a  simple  parser  that 
recognizes  functions  or  macros  defined  :n  the  source 
code  but  ignores  common  library  routines  such  as 
print/O  or  scanff).  (An  al'ernate  pre-processor  can 
include  all  functions  called.)  Function  names  are 
stored  in  namefile  which  is  then  used  by  the  parser  in 
eacn  tool  to  recognize  routines  of  interest.  This 
design  allows  the  analyst  to  remove  names  of  routines 
that  are  not  security-relevant,  such  as  matli  library 
functions.  The  output  of  a  tool  (e.g.  a  call  tree)  will 
then  consider  only  security-related  routines,  simplify¬ 
ing  the  analysis,  Of  course,  judgement  is  required  to 
determine  what  functions  can  be  safely  ignored. 
NamejiL  can  be  edited  repeatedly  to  provide  different 
views  of  the  system  being  studied. 


2.1.  Operation 

Ccal/s  has  two  phases.  First  a  file  of  routine 
names  and  the  file  where  they  are  defined  is  produced. 
The  second  phase  reads  this  file  and  begins  parsing 
the  C  source  code.  An  adjacency  matrix  D  is  built, 
where  D,.;  is  1  if  routine  i  calls  routine  j  and  is  0 
otherwise.  In  other  words,  D  is  simply  a  matrix 
representation  of  the  program’s  call  graph.  After  D  is 
completed,  t calls  builds  a  matrix  I  =  D‘,  the  transi¬ 
tive  closure  of  D.  D  is  called  the  direct  call  matrix 
and  I  is  called  the  indirect  call  matrix,  since  I 
represents  the  indirect  relationship  between  routines 
through  calls.  In  the  example  discussed  above, 
r>A  B  =  i,  and  Ds.<-  —  1,  since  A  calls  B  and  B  calls  C. 
Also,  I*#  because  of  the  indirect  relationship 

between  A  and  C. 

2.2.  Call  Tree 

After  the  call  matrix  is  built,  a  call  tree  is  easily 
produced.  A  portion  of  one  is  shown  Figure  2.  Cecils 
only  expands  a  subtree  fully  the  first  time  a  routine  is 
encountered.  Thus  in  the  example  in  Figure  2,  if 
'prtjinc'  were  called  elsewhere,  the  tree  would  not  he 


Flgur*  1.  Tool  Design 


2.  Ccalls:  Call  Tree  and  Logical  Nesting 

The  first  task  of  the  security  analyst  is  to  under¬ 
stand  the  program  that  is  being  evaluated.  The  first 
step  in  doing  tills  is  to  look  at  the  functions  of  indivi¬ 
dual  routines  and  the  calls  they  make  to  other  rou¬ 
tines,  In  addition  to  the  calls  that  occur  in  the  pro¬ 
gram,  the  analyst  will  be  interested  in  the  indirect 
relationships  among  routines.  If  routine  A  calls  rou¬ 
tine  B,  and  B  calls  C,  then  a  change  to  A  may  affect 
C,  or  a  change  to  C  may  affect  A  through  parameters 
passed  in  calls.  This  relationship  can  be  traced  from 
the  call  tree,  but  if  a  program  contains  many  routines 
the  call  tree  may  be  spread  across  several  pages  of 
paper,  making  it  awkward  to  analyze.  The  tool 
presented  in  this  section,  called  (calls  simplifies  the 
analysis  of  these  relationships,  Several  tools  are  avail¬ 
able  to  perform  some  of  the  functions  of  ccalls,  but 
ccalls  is  apparently  the  first  such  tool  to  Identify  logi¬ 
cal  nesting  in  C  source  (see  Section  2.7).  It  also 
appears  to  be  the  only  tool  to  extract  an  indirect  calls 
matrix  from  C  source  code,  although  it  is  possible  to 
trace  indirect  calls  manually  using  a  call  tree, 


expanded  to  show  ‘get_namc’  as  a  subroutine  of 
‘prtjine’.  This  helps  keep  the  call  tree  display  to  a 
reasonable  size. 

The  UNIX  System  V  utility  cflow  provides  a 
similar  call  tree  but  lists  calls  to  library  functions  such 
as  printJO  and  getchar().  This  results  in  extremely 
large  call  trees  which  may  make  it  harder  to  recognize 
the  structure  of  the  program.  Ccalls  was  designed  to 
eliminate  this  “information  overload’’  by  ignoring 
library  routines  and  printing  calls  within  routines  only 
once.  If  desired,  a  different  pre-processor  can  be  used 
with  c calls  to  include  all  functions,  whether  they  are 
defined  in  the  system  under  study  or  are  library  func¬ 
tions. 

The  call  tree  lines  are  of  the  form  routine 
namc:fiie  in  which  routine  is  defined  and  may  be  fol¬ 
lowed  by  an  asterisk  If  the  routine  represents  the  root 
of  a  logically  nested  subsystem  (as  explained  in  Sec¬ 
tion  2.7). 

2.3.  Call  Matrix 

Rather  than  present  a  large  square  matrix  of  Is 
and  Os,  ccalls  provides,  for  each  routine  in  the  pro- 
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From  lilc:  maMix.c 


grain,  lists  of  the  routines  that  il-  calls  directly  and 
indirectly  and  lists  of  routines  :1ml-  call  it  directly  and 
indirectly.  An  example  is  shown  in  Figure  ,'i. 

2.4.  Statistics 

('calls  also  provides  some  statistics  that-  may  lie 
useful  in  estimating  the  complexity  of  the  program 
being  evaluated.  Figure  I  shows  an  example.  The 
value  Functions  is  simply  a  count  of  the  C  functions 

nmimmain.e  * 

closuretmalrix.e 
copyji  rraymiat  rix.c 
init_a  fray  mint  rix.c 
oiil_malrix:matrix.c  * 

count  Jnl  efface!': mill  rix.c 
do_eall_lree:mal  rix.c 
in:dn_rt  mproc.c 
prl  Jineunal  rix.c 

gel_iiamc:prof.c 

pr t _ t  remiatrix.c 

add Jt  i  misct.c 
prl  Jineunal  rix.c 
prt_t  retinal  rix.c 
set_im'iii:set  ,e 


Figure  2.  K.valnple  of  Call  Tree 

or  routines  in  tile  entire  program.  Interfaces  is  a 
count  of  the  in  terraces  between  routines.  For  exam¬ 
ple,  if  A  calls  1!  three  times  and  calls  (’  twice,  there 
are  two  interfaces:  A  to  H  and  A  to  C.  1  lie  Number 
of  Calls  in  this  example  is  of  course  live. 

The  ratios  provide  some  information  on  the 
branching  factor  of  the  call  tree.  I  he  main  routine. 
Winn  in  standard  C,  is  not  included  in  the  count, 
otilv  subroutines.  Moth  ratios  thus  have  minimum 
values  of  l .CM),  since  every  routine  hut  mum  must  he 
called  at  least  once,  {mills  can  identify  routines  not 
called.) 

2.5.  Uncalled  Routines 

Routines  that  arc  never  called  are  easily 
identilied  using  the  direct  call  matrix  D  I  he  routine 
indexed  by  j  is  utilised  if  D,,,  o  for  all  i  '1  hose 
routines  are  listed  on  the  analysts  report,  I  lie  UNIX 
tool  lint  can  detect-  uncalled  routines,  hut  some  rou¬ 
tines  may  he  called  yet  still  he  unreachable.  For 
exam  pita  routine  il  in  Figure  ■>  is  uncjled  nnd 
unreachable.  Routines  c  and  /  are  unreachable  hut 
not  uncalled,  (‘culls  can  detect  these  unreachable 
routines,  as  explained  ill  the  next  section. 


do_rall  J  roe: 

Calls: 

Directly: 

ninin_rln  prtjine  prl_tro 
Indirectly: 

addjtem  get_natne  niHili _ rtn 

prtjine  prt_t.ro  scl_enipty 
set_niem  set jiiiimi  suhs.vs 

Called  My: 

Directly: 

out_mairix 

Indirectly; 

main  oiit_matri.x 

Figure  3.  Display  of  Call  Matrix 


. STATISTICS . 

Fund  ions:  31 
Interfaces:  3(> 

Calls:  •!() 

Intei'fiiccs/Fmicfioii:  1.0(1 

Calls/Fiincliom  1. 44 


Figure  4.  Kxamplc  of  Statistics 


Figure  6.  Uncalled  and  Unreachable  Routines 
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2.0.  Unreachable  Routines 

Some  routines  that  arc  never  called  may  call 
other  routines.  These  other  routines  will  not  appear 
on  the  list  of  uncalled  routines  even  though  there  n.»y 
be  no  possible  execution  of  the  program  in  which  they 
could  he  called.  Recall  that  I  —  D\  Therefore  I,.,  -  1 
if  and  only  if  there  is  some  call  sequence  from  i  to  }■ 
Unreachable  routines  can  be  identified  simply  by 
finding  those  which  cannot  be  reached  by  any  calling 
sequence  from  main,  i.e.,  the  routine  indexed  hy  j  is 
unreachable  if  I*.,,.,-  -  <>.  Note  that  it  is  always  true 

that 

[one  nit:  it  routines}  C  {uiireneliMc  routines } 
Unreachable  routines  arc  listed  on  the  analysis  report. 

Routines  that  are  called  only  through  function 
pointers  will  be  listed  as  uncalled  and  unreachable. 
The  analyst  must  check  that  each  such  routine  is 
used  and  that  it  is  possible  for  a  function  pointer  to 
be  instantiated  with  the  routine’s  address. 

2.7.  Logical  Nesting 

A  useful  feature  of  ccalls  is  the  Identification  ol 
logically  nested  subsystems,  marked  with  an  asterisk 
in  Figure  2.  Block  structured  languages  such  as-  Ras¬ 
cal  and  Rl./l  allow  routines  to  be  nested,  to  explicitly 
show  their  hierarchical  relationship.  The  C  language 
does  not  provide  this  feature,  so  hierarchical  arrange¬ 
ments  of  subroutines  must  be  deduced  from  the  cal¬ 
ling  structure.  Ccalls  saves  time  by  performing  this 
task  for  the  analyst.  The  value  of  recognizing  a  logi¬ 
cally  nested  subsystem  is  that  one  can  study  the  sub¬ 
system  independently  from  the  rest  of  the  code. 

We  define  a  logically  nested  subsystem  as  a  group 
of  routines,  headed  by  a  root  node,  none  of  which  is 
called  by  any  routine  that  is  not  part  of  the  subsys¬ 
tem.  Tims  leaf  nodes,  i.e.  routines  that  do  not  call 
other  routines,  are  trivially  subsystems.  1  lie 
definition  is  stated  formally  in  Figure  (i.  The 
definition  indicates  if  a  particular  node.  r.  is  the  root 
of  a  logically  nested  subsystem,  E  is  a  set  of  routines 
'external'  to  the  subsystem  (if  one  exists  headed  by- 
node  r),  C  is  the  set  of  routines  called  by  ••onlines  in 
set  and  r  and  j  are  indices  of  routines  in  the  pro¬ 
gram.  Ccalls  prints  an  asterisk  adjacent  to  any  rou¬ 
tine  that  is  the  root  of  a  logically  nested  subsystem. 

A  program  will  typically  contain  ‘library’  routines 
that  are  used  in  many  places.  Ccalls  allows  the  user 
to  eliminate  these  library  routines  from  consideration 
when  checking  for  logical  nesting. 

2.8.  Data  Access 

An  option  allows  global  variables  to  be  included 
ill  the  analysis.  Heavy  use  of  global  variables  is  poor 
programming  practice.  However,  there  are  cases  where 


a  --  -  {  r ; 

i:  u  ■  s 

<-=UA.' 

nE 

(i’PjC  =  0)  =  r  is  the  root  node  of  a  logically  nested 
subsystem 

where 

U  -  the  set  of  all  reachable  routines  in  the  program 
I,  ,  tlie  set  of  routines  called  indirectly  by  r, 
corresponding  to  row  r  of  matrix  I. 

.  -  tlie  set  of  routines  called  directly  by  i, 
corresponding  to  row  i  of  matrix  D. 

Figure  6.  Logically  Nested  Subsystem  identification 

they  can  lie  used  sensibly.  I1  or  example,  a  common 
way  to  implement  an  abstract  data  type  ii  C  is  to 
define  a  data  structure  and  all  functions  that  access  it 
in  a  single  file.  The  data  structure  must  be  global  to 
all  the  functions  in  the  file.  Ccalls  allows  global  vari¬ 
able  names  to  be  treated  as  "functions''  and  appear  in 
tlie  call  tree  (as  leaf  nodes)  so  the  analyst  can  examine 
the  different  ways  in  which  functions  accessing  a  glo¬ 
bal  variable  can  be  reached.  The  system  should  per¬ 
form  necessary  validations  on  nil  calling  sequences 
which  can  reach  critical  variables.  Including  global 
variables  as  leaf  nodes  in  the  call  tree  can  make  it 
easier  to  trace  what,  happens  on  the  wav  to  a  function 
that  accesses  a  critical  data  item.  Another  tool, 
described  in  tlie  next-  section,  unravels  the  call  tree 
into  all  possible  calling  sequences  to  make  it  easier  to 
trace  events  along  paths  to  critical  functions  and  data 
items. 

3.  Paths:  All  Calling  Sequences 

One  check  that  must  lie  made  is  to  ensure  that 
preconditions  for  routines  are  established  and/or 
maintained  by  routines  higher  up  in  the  calling 
sequence.  This  is  particularly  important  in  assembler 
language  where  parameters  are  passed  in  registers  or 
global  variables.  To  verify  that  preconditions  are  met 
before  a  routine  is  called,  the  analyst  must  trace 
upward  through  all  possible  paths  in  the  call  tree  by 
which  a  routine  can  be  readied  and  ensure  that  regis¬ 
ters  are  set  up  correctly  on  all  pa»hs.  This  process  is 
made  easier  by  generating  all  possible  calling 
sequences  in  which  bottom  level  routines  can  be 
readied.  The  list  of  all  sequences  is  restricted  to  those 
that  contain  the  routine  of  interest  by  passing  the  tool 
output  through  grep.  The  analyst  can  then  check 
each  of  the  call  sequences  as  Tar  up  as  necessary  to 
verify  preconditions.  An  example  is  shown  in  Figure 


293 


7.  Lists  start  with  lowest  level  routines  and  move  up 
the  tree  from  left  to  right.  For  example,  the  first  list 
shows  that  main  calls  csm_errproc  which  calls 
$cni_esm  and  so  on. 

key_setup<-csm_macproe<-gen_edc<-putede<- 
send_esm  <-csm_errproc  <-main 

key_setup  <-csm_macproc  <-gen_edc  < -putedc  <  - 
send_esm  <-csm_errproc  <-pl_csm_parse  <  - 
getcsm<-main 

key_setup<-csm_rnacproc<-gen_edc<-putedc<” 

send_esm<-main 

Figure  7.  Calling  Sequences 

4.  Layers:  An  Alternative  View  of  Program 
Structure 

We  have  been  experimenting  with  different  ways 
of  displaying  program  structure.  One  interesting 
approach  is  shown  in  Figure  8*.  The  matrix  was 
created  by  dividing  the  program  into  layers  according 


to  calling  structure.  The  top  layer  l  D  is  define  *  to  be 
{mem},  Other  layers  can  then  be  defined  as 

L%  =—  (function  called  from  layer  L,_ i  not  aetijned  to  a 
laye r  m,  rr.  <  n  }. 

More  formally, 

Lo  **>  {  mom  }, 

L,  =  {  J  :  for  tome  i  e  L„_i,  i  colie  j  L*  for 
all  m  <  n  } , 

where  i  and  j  are  functions, 

A  cal!  from  routine  i  to  routine  j  is  shown  by 
“XX"  at  position  j  in  the  matrix.  The  index 
numbers  are  keyed  to  function  names  and  are 
displayed  on  a  separate  page  or  another  workstation 
window. 

This  type  of  presentation  is  useful  not  only  as  a 
way  to  give  a  complete  cross  reference  on  one  page 
(for  the  size  of  systems  under  evaluation)  but  also  to 
convey  information  about  the  structure  (or  lack 
thereof)  of  the  system.  In  particular  it  shows  the 
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Figure  0.  Example  of  Layers 


(lepemlettee  relation  among  routines.  The  relation  is 
very  similar,  hut  not  equivalent,  to  the  USES  relation 
tiffined  by  I’arnas  [I’aniTd,  NIJL80,  NenmSti]  beeanse 
it  is  derived  purely  from  static  analysis  of  source  code 
which  can  only  recognize  syntactic  uses  of  functions. 
Nevertheless,  we  have  found  it  helpful  in  recognizing 
levels  of  abstraction  that  nitty  not  be  immediately 
apparent  front  source  cotie  packaging,  a  problem  that 
occurs  in  many  evaluations,  particularly  in  secure 
UNIX  implementations  |Sibe87]. 

An  imponm  principle  of  software  engineering 
holds  that  reliability  is  enhanced  by  organizing  a  sys¬ 
tem  into  a  hierarchy  of  layers  [Dijkns],  Each  layer  of 
subroutines  provides  a  virtual  machine  whose  func¬ 
tions  are  used  to  implement  the  next  higher  layer. 

*  Figures  8  ami  !)  are  small  utilities  used  for  illustration. 


More  recently  it  lias  been  argued  that  the  same 
arrangement  supports  security  concerns,  espeeially 
verillcnlion  jNeumSti]. 

Well  designed  systems  are  often  organized  into 
layers,  and  as  a  result  it  is  often  helpful  in  under¬ 
standing  a  system  to  categorize  subroutines  liv  fimc- 
lionai  layer.  Of  course,  many  routines  may  lie  used  in 
several  places  te.g.  math  subroutines).  These  can  be 
considered  general-purpose  library  routines  rather 
limn  members  of  any  particular  layer.  From  running 
the  tool  on  many  different  systems,  it  appeals  that 
most  tend  to  show  a  layered  arrangement  even  when 
this  was  not  an  explicit  design  requirement. 

1  he  layers  in  Figure  8  correspond  to  nesting  lev¬ 
els  at  which  routines  Hist  appear  in  the  call  tree,  i.o. 
main  which  first  appears  at  nesting  level  0  is  layer  0, 
functions  that  first  appear  at  nesting  level  1  are  in 
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layer  1  and  so  on.  Calls  from  t mictions  at  lower  levels 
to  higher  levels  (level  i  +1  considered  “lower"  than 
level  i  )  appear  in  the  lower  left  corner  of  the 
diagram.  Calls  of  this  type  may  be  an  Indication  of 
poor  structuring. 

Figures  8  r  ad  0  show  an  interesting  contrast. 
The  systcv  in  Figure  8  is  nicely  layered.  To  gain  an 
understandinb  of  this  system,  the  analyst  can  proceed 
by  studying  routines  in  increments  of  reasonable  sine, 
in  the  system  in  Figure  0,  Id  of  the  GO  functions  are 
called  within  the  first  two  layers.  The  analyst  must 
study  almost  75%  of  the  functions  at  once  to  see  how 
the  system  works.  In  addition,  this  system  contains 
many  routines  that  are  called  from  several  layers, 
where  the  one  in  Figure  8  has  only  a  few  such  rou¬ 
tines. 

5.  Assert:  Assertion  Recognizer 

Treasury  Department  requirements  [TrenSGb] 
specify  critical  events  that  must  he  performed  by  the 
EFT  equipment,  e.g.  "Inhibit  interrupts  for  crypto 
processing",  “Perform  PAM  test."  To  make  it  easier 
to  check  that  these  functions  arc  being  performed 
properly,  source  code  is  required  to  contain  numbered 
assertions  that  help  the  analyst  recognize  important 
points  in  the  code.  The  following  assertions  are 
required; 

1.  module  name, 

2.  global  data  items, 
ii.  local  data  items, 

4.  module  housekeeping  prior  to  return, 

5.  requirements  performed  prior  to  module  entry, 

5.  requirements  performed  during  module  profess¬ 
ing, 

7.  other  modules  accessed  during  processing  of  given 
module, 

8.  other  modules  that  can  access  Lite  given  module. 
For  example,  the  assertion  format  for  hem  5 

above  is 

ASSERT  4  5  < category  of  event  >  <cvenl>. 

'file  categories  and  events  are  specified  am!  num¬ 
bered  In  the  requirements,  so,  for  example,  “MID  gen¬ 
eration"  would  be  indicated  by 
ASSERT  4  5  11. 

The  evaluation  suite  includes  a  tool  to  recognize 
assertions  and  write  out  the  assertion,  line  number  on 
which  it  starts,  and  the  file  in  which  it  occurs.  The 
same  function  may  also  be  performed  with  the  UNIX 
tool  grey  if  the  assertions  are  not  broken  across  two 
or  more  lines.  Using  additional  UNIX  tools  such  as 
awk,  sort,  and  uniq  simple  scripts  check  that  all 
required  events  have  been  asserted  in  the  code,  'flic 
analyst  must  then  verify  that  they  are  being  per¬ 
formed  correctly  and  at  the  proper  times. 


8.  Ccomments:  Condensed  Source  Listing 

Often,  the  best  way  to  get  an  idea  of  what  a  pro¬ 
gram  docs  is  to  proceed  in  a  top-down  fashion,  deter¬ 
mining  the  function  of  the  top-level  routine,  then 
looking  for  calls  to  other  routines  and  determining 
their  functions.  The  important  points  to  consider 
about  tlie  routines  are  the  parameters,  and  com¬ 
ments  in  the  source  code  telling  what  the  routine 
does. 

A  ‘condensed  source  listing’  is  provided  that 
abstracts  this  information  from  the  source  code  to 
provide  a  summary  of  the  program.  The  condensed 
source  listing  is  designed  to  make  it  easier  to  study 
the  functions  in  a  large  program.  It  gives  comment 
header  blocks  and  the  call  interface  to  each  routine. 
Hie  call  tree  provided  by  ccatls  provides  a  ‘road  map’ 
of  the  program’s  structure  and  serves  as  a  guide  to 
using  the  condensed  source  listing.  An  example  is 
shown  in  Figure  10. 

7.  Metrical  “Quality  Metrics" 

One  Important  consideration  in  evaluations  is  the 
degree  to  which  good  programming  practices  have 
been  followed.  Interesting  characteristics  include 
lengths  oi  routines,  number  of  comment  linns,  number 
oi  declaration  lines,  ratio  of  comments  to  executable 
code,  and  "complexity  metrics"  such  us  McCabe's 
cyclomutic  number  metric  |McCa70|,  Another  tool  in 
the  evaluation  suite  cheeks  and  reports  on  these  sur¬ 
face  characteristics,  it  also  gives  warnings  at  user 
determined  thresholds  for  lengthy  routines,  insufficient 
comments,  or  cyclomatic  number  greater  than  a  user- 
spec'ilied  value  (typically  10). 

8.  Trace:  Function  Call  Trace 

It  is  Important  that  asserted  events  he  performed 
in  the  proper  order.  The  tool  set  also  Includes  one 
dynamic  analysis  tool  that  instruments  C  source  code 
to  print  the  name  of  s>.  routine  whenever  it  is  exe¬ 
cuted.  This  makes  it  possible  to  test  a  system  and 
cheek  that  critical  functions  are  being  performed  in 
the  correct  order  by  examining  the  trace  of  function 
calls. 


0.  Future  Work 

B.l.  Windowing  Environment  for  Certification 
Tools 

We  will  be  developing  a  prototype  of  an 
integrated  windowing  environment  in  which  the 
security  analyst  can  operate  the  previously  developed 
tools  or  any  others  that  are  available  from  other 
sources  (e.g.  standard  UNIX  utilities)  or  may  he 
developed  in  the  future. 
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/*  Source  File  name  =  CSMUTIL.C  -  X9.17  Utility  Junctions  */ 

/*  Parse  KD/KX/*KK,  etc.  field  and  extract  subfields  */ 

V_field_parse  (buf_offset,  key_area) 
int  buf_offset; 
struct  kcy_f ield  *key_area; 


/***.*. ************. *********»******;******». *.**************'«  *********/ 
/*  Parse  KID  field  in  a  G$K  Pseudo  Message  -  get  subfields  */ 

/A******************* ft************************** *************  ****»**«»*/ 

kidfield.j?arse  (buf_offset,  kicLarea) 
int  buf_o  f  fset; 
struct  kid_field  *l<id_area; 


/*  Parse  SVR  field  and  extract  subfields  */ 

svr_fielcLparse  (buf_offset,  svr_area) 
int  buf^offset; 
struct  svr_field  *svr_area; 


Figure  10.  Condensed  Source  Listing 


The  environment  will 

1.  Provide  up  to  four  windows  simultaneously,  with 
each  window  able  to  display  or  edit  a  file  gen¬ 
erated  by  the  tools. 

2.  Execute  a  tool  from  any  window. 

3.  Provide  a  menu  of  functions  to  perform  and  tools 
to  execute. 

4.  Allow  escape  to  the  UNIX  shell  without  leaving 
the  environment. 

f>.  Be  able  to  rceontlgure  the  windows  from  one  to 
four  and  change  their  sizes  as  desired  by  the 
security  analyst, 

0.  Oeate  Hies  and  directories  to  store  results  of  a 
session. 

9.2.  Sequence  Analysis  Tool 

Among  the  requirements  for  the  EFT  software 
are  requirements  that  certain  security  critical  opera¬ 
tions  are  performed  in  a  specified  sequence,  in  addi¬ 
tion  to  the  operations  that  perform  tic  encryption 
and  decryption  [TrcaSObj.  Examples  include  the 
checking  of  critical  routines  before  they  are  executed 
and  the  clearing  of  sensitive  data  from  temporary 
storage  after  use.  The  critical  operations  must  be  per¬ 
formed  in  proper  sequence  on  all  paths  through  the 
program. 

By  using  data  and  control  How  analysis  tech¬ 
niques  developed  for  optimizing  compilers,  it  is  possi¬ 
ble  to  determine  if  many  sequencing  constraints  are 
met  [OlenxB),[Mcl,c84].  In  addition  to  use  in  optimiz¬ 
ing  compilers,  analysis  of  this  type  has  been  used  in 
evaluation  of  software  reliability  [Fosd7G].  It  may 
also  be  of  value  in  evaluating  software  security. 


To  assist  the  security  analyst  in  evaluating  EFT 
software,  a  tool  is  being  developed  that  will  accept  a 
specification  of  event  sequences  from  the  analyst  and 
determine  through  static  evaluation  if  the  sequence 
constraint  is  met.  Tile  following  types  of  event 
sequences  can  be  chocked  for: 

1  *  Does  A  ever  occur  before  B? 

2  -  Docs  A  always  occur  before  B? 

3  -  Does  A  ever  occur  after  B? 

4  -  Does  A  always  occur  after  B? 

5  -  Does  A  ever  occur  immediately  before  B? 

6  -  Does  A  always  occur  immediately  before  U'i 

7  -  Does  A  ever  occur  immediately  after  B? 

8  -  Does  A  always  occur  immediately  after  B? 

To  make  the  analysis  practical,  the  events  should 
correspond  to  functions  (or  subroutines)  in  the  source 
code.  This  should  lie  a  reasonable  constraint,  since 
the  development  requirements  (TreaHdb]  specify  that  a 
subroutine  should  perform  only  a  single  function  and 
also  require  assertions  to  be  placed  in  the  source  code 
to  assist  tile  analyst  in  determining  where  critical 
functions  are  performed.  It  should  then  be  possible 
for  the  tool  to  answer  questions  given  above  based  on 
syntactically  possible  sequences  of  subroutine  calls. 

10.  Conclusions 

The  tools  described  in  this  paper  are  experimen¬ 
tal.  All  appear  to  be  useful,  but  more  experience  is 
required  to  determine  those  that  arc  most  effective  in 
aiding  evaluations,  and  to  determine  features  that  are 
missing.  We  would  like  to  obtain  good  data  How 
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analysis  tools  for  C,  to  supplement  the  fairly  basic 
capabilities  of  lint  and  our  own  tools.  Although  the 
tools  are  now  being  used  on  relatively  small  systems, 
the  Department  of  Treasury  has  very  large  systems 
that  process  sensitive  data.  Another  goal  of  our 
current  work  is  to  determine  how  the  tools  can  be 
applied  to  large  systems. 
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Abstract 


This  paper  describes  how  a  software-based  security 
architecture  can  protect  itself  against  programs  that  attempt  to 
compromise  system  security.  Methods  of  program 
containment  are  explained,  using  an  example  of  a  software- 
based  security  architecture:  the  Unisys  A  Series  with  the 
MCP/AS  operating  system  and  InfoGuard  security 
enhancements.  The  presentation  focuses  on  issues  involving 
creation  and  protection  of  program  code  and  the  extent  to 
which  compilers  are  included  in  the  Trusted  Computing  Base 
(TCB). 


Introduction 


System  security  is  usually  considered  "stronger"  when  based 
upon  a  hardware  architecture  that  enforces  TCB  constraints. 
Therefore,  techniques  for  building  a  software  architecture  that 
enforces  TCB  constraints  are  less  widely  discussed.  A  security 
architecture  that  relies  in  large  part  on  a  software  TCB 
requires  that  novel  methods  of  program  containment  be 
developed.  The  threat  of  system  security  being  compromised 
by  user-written  programs  must  be  analyzed  carefully  in  an 
environment  where  the  hardware  is  supportive  of,  rather  than 
primarily  responsible  for,  enforcement  of  security. 

The  next  section  of  this  paper  surveys  the  central  role  played 
by  program  code  in  threats  to  a  software-based  security 
architecture.  The  subsequent  section  introduces  the  Unisys 
A  Series  architecture  as  an  example  of  a  software-enforced 
TCB.  Then  the  largest  section  of  the  paper  is  devoted  to  an 
examination  of  the  A  Series  protection  methods  that  provide 
program  containment;  the  issues  covered  include  the  nature 
and  extent  of  trust  in  compilers,  as  well  as  the  controls  that 
must  be  placed  on  both  compilers  and  the  programs  they 
create.  The  term  "code  file"  is  used  throughout  in  the  A  Series 
sense,  referring  to  a  file  that  contains  compiler-generated, 
machine-executable  code. 

This  introductory  section  concludes  with  a  very  brief  overview 
of  the  Unisys  A  Series.  The  basic  architecture  was  introduced 
in  the  late  1960s  with  the  Burroughs  B6500  (which  was  itself 
based  on  the  earlier  B5500)  and  evolved  through  the  other 
B6000  and  B7000  systems  to  the  A  Series  line,  Although  each 
new  step  in  the  evolutionary  process  provides  object-code 
compatibility  between  new  and  predecessor  systems,  the 
hardware  and  software  architecture  does  indeed  change  over 
time. 

At  a  high  level  of  abstraction,  the  Unisys  A  Series  operating 
system,  Master  Control  Program  /  Advanced  System 
(MCP/AS),  is  primarily  responsible  for  enforcing  the  A  Series 
security  policy  with  respect  to  users,  files,  programs,  and 
processes  (some  security  enhancements  are  enabled  by 
InfoGuard,  a  Unisys  software  product  that  is  integrated  with 


MCP/AS):  high-level  protection  incorporates  the  principles  of 
Discretionary  Access  Control  (DAC),  Identification  and 
Authentication,  Audit,  Object  Reuse,  and  Least  Privilege  as 
required  for  Class  C2  of  the  Trusted  Computer  System 
Evaluation  Criteria  [DoD85],  At  a  low  level  of  abstraction, 
central-memory  objects  are  protected  by  a  combination  of 
hardware,  microcode,  the  MCP/AS  security  "kernel",  and 
compilers;  low-level  protection  is  accomplished  by  structural 
containment  (i.e.,  access  is  limited  by  the  structure  of  the 
environment). 

Although  A  Series  processors  do  not  define  a  privileged 
execution  state,  they  do  provide  a  number  of  protection 
features:  a  4-bit  tag  is  associated  with  each  48-bit  memory 
word;  tag  values  discriminate  data  from  code  and  various 
processor  control  words.  Code  and  critical  control  words  have 
odd  tags  and  are  thus  protected  from  access  or  modification  by 
the  instructions  normally  used  to  manipulate  data.  Memory  is 
managed  in  segments  defined  by  special  control  words  called 
descriptors.  All  accesses  to  data  segments  (e.g„  arrays)  are 
automatically  bounds-checkcd.  A  sophisticated  stack-based 
addressing  mechanism  allows  each  item  declared  in  a  block- 
structured  program  to  be  assigned  a  static  address  at  compile 
time;  the  addressed  location  may  contain  a  simple  variable 
(tag  0  or  2)  or  a  tag-differentiated  item  such  as  an  array 
descriptor  (lag  5),  a  pointer  to  a  character  (tag  5),  an  entry 
point  to  a  procedure  (tag  7),  or  a  reference  to  another  item 
(tag  1). 

The  environment  of  any  process  consists  of  its  own  code  and 
data  plus  any  other  items  that  are  provided  to  it  for 
communication  with  other  processes  or  the  operating  system. 
Because  each  item  can  be  separately  described,  the 
architecture  permits  controlled  sharing  of  information  at  an 
arbitrarily  fine  level  of  detail.  Thus  each  instance  of  a  process 
(actually,  each  procedure  invocation)  has  its  own  execution 
domain  in  an  A  Series  system;  hardware  changes  context 
automatically  on  procedure  invocations  across  process 
domains.  Indeed,  it  is  just  this  flexibility  of  domain  structure 
that  justifies  involving  software  in  protection  enforcement, 
rather  than  relying  exclusively  upon  simple  isolation 
mechanisms  in  hardware.  (For  an  illustration  of  process 
domains,  refer  to  the  Appendix.) 

Ancestral  versions  of  the  architecture  are  described  by  Hauck 
and  Dent  [Hau68],  Creech  [Cre69],  Organick  [Org73],  and 
Doran  [Dor791.  The  most  significant  architectural  departure  in 
the  A  Series  Advanced  System  Architecture  is  the  introduction 
of  Actual  Segment  Descriptors  (ASDs)  to  extend  the  virtual 
and  physical  addressing  space:  the  virtual  segment  descriptors 
that  define  data  and  code  segments  refer  to  an  ASD  rather 
than  directly  to  a  memory  address  [Mem87], 


Potential  Problems  with  Code  Files 


In  hardware  architectures  that  support  two  execution  states, 
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privileged  and  non-privileged,  the  processor  enforces 
containment  of  non-privilegea  code  by  permitting  dangerous 
operations  only  in  privileged  state.  However,  if  tne  hardware 
supports  only  one  execution  state,  the  system  software  must  be 
responsible  for  supporting  privileged  and  non-privileged 
operations,  while  protecting  the  boundaries  of  the  TCB.  Those 
parts  of  the  system  software  that  create  and  maintain  a  self- 
protecting  domain  of  execution  must  therefore  be  trusted, 
increasing  the  size  of  the  TCB. 

If  the  hardware  has  a  single  execution  state,  arbitrarily 
constructed  code  sequences  are  capable  of  subverting  system 
security.  In  such  an  architecture,  one  of  the  most  critical 
aspects  of  TCB  protection  is  the  control  of  executable  program 
code.  Several  vulnerabilities  relating  to  program  code  must  be 
considered  and  neutralized  in  order  to  preserve  the  integrity  of 
a  software-enforced  TCB. 


Access  to  Assembly  Language 

The  most  obvious  vulnerability  of  a  software-enforced  TCB  is 
the  ease  with  which  assembly  language  programs  are  able  to 
subvert  system  security.  Without  Hardware  controls,  any 
system  is  inherently  insecure  if  an  assembler  is  available  that 
can  create  arbitrary,  executable,  machine-language  programs. 


Coercion  of  Valid  Compilers 

Limiting  programmers  to  use  of  high-level  languages  is  not  a 
sufficient  means  of  guaranteeing  the  integrity  of  a  software- 
enforced  TCB.  As  Gligor  points  out  [GH83], 

"Attempts  to  force  programmers  to  use  only  high-level 
languages,  ...  which  would  obscure  the  processor 
instruction  set,  arc  counterproductive  because  arbitrary 
addressing  patterns  and  instruction  sequences  can  still  be 
constructed  through  seemingly  valid  programs;  i.e„ 
programs  that  compile  correctly.' 

If  a  compiler  provides  a  user  with  an  overt  capability  to 
generate  arbitrary  code  sequences,  perhaps  via  specific 
language  constructs,  the  TCB  is  once  again  vulnerable  to 
subversion. 

However,  a  language  specification  that  does  not  provide  an 
overt  means  for  generation  of  arbitrary  code  sequences  may  be 
implemented  by  a  compiler  with  less  obvious  vulnerabilities. 
According  to  Landwehr  [Lan87], 

"In  practice,  it  is  difficult  to  prevent  users  from 
generating,  via  a  certified  compiler,  programs  that  violate 
security,  because  compilers  can  often  Be  subtly  coerced 
into  generating  and  initiating  execution  of  arbitrary  bit 
strings." 

From  the  above  arguments,  it  becomes  more  evident  that  trust 
in  a  compiler  is  a  critical  aspect  of  a  software-enforced  TCB.  It 
follows  tnat  creation  and  installation  of  a  compiler  are  points 
of  vulnerability  that  require  serious  consideration. 


User-Created  Compilers 

If  a  user  is  allowed  to  create  his  own  compiler,  he  has  the 
ability  to  generate  any  code  sequence  desired,  Likewise,  if  the 
user  is  able  to  introduce  a  compiler  to  a  system  from  off-line 
storage  or  from  another  host,  he  may  go  to  a  less  secure 
system,  alter  an  otherwise  valid  compiler  or  hand-craft  his  own 
compiler,  and  then  import  it  into  the  system,  perhaps  as  a 
Trojan  Horse, 

Landwehr  [Lan87]  points  out  that  Burroughs  systems  have 
relied  on  software  controls  that  allow  users  to  program  only  in 
higher  order  languages  compiled  by  certifiea  compilers. 


Landwehr  cites  an  example  [Wil81]  of  how  the  software 
controls  failed  to  prevent  users  from  creating  their  own 
compilers  to  generate  insecure  assembly  language  programs. 


Code  Modification 

Modification  of  program  code  after  compilation  presents 
another  vulnerability  (see  Figure  1).  Changing  program  code 
in  memory  creates  a  temporary  (or  dynamic)  capability  to 
circumvent  system  security,  If  the  modification  can  be  made  to 
code  stored  on  tape,  disk,  or  any  other  storage  medium, 
security  can  be  compromised  more  permanently.  In  the 
example  cited  by  Landwehr,  the  key  to  user  creation  of  a 
compiler  was  actually  the  ability  to  modify  a  code  file  stored  on 
magnetic  tape. 


Figure  1.  Code  Is  vulnerable  to  modification. 


Constraints  on  the  construction  (compilation)  of  code  would  be 
of  no  avail  if  the  code  were  subject  to  modification  while  being 
executed  in  memory,  Code-modifying  programs  provide  a 
more  serious  threat  to  software-protected  systems  than  to 
other  systems.  A  program  might  appear  benign  on  disk, 
waiting  until  it  is  actually  executed  to  modify  its  own  code  in  a 
dangerous  way.  Such  a  program  might  also  modify  the  code  of 
another  process  that  is  resident  in  memory,  thus  infecting  other 
processes  with  dangerous  code.  A  way  to  stop  this  type  of  virus 
is  needed. 


A  system  that  depends  upon  tape  label  records  is  vulnerable  to 
any  mechanism  that  permits  tne  label  records  to  be  read  and 
written  as  ordinary  data.  Such  abuse  of  "unlabelled"  tape 
access  was  essential  to  the  penetration  of  a  Burroughs  B6700 
system  described  by  Wilkinson  [Wil81]: 

"An  ordinary  unprivileged  user  with  sufficient  knowledge 
of  the  system  needs  only  the  ability  to  be  able  to  modify 
machine-code  in  order  to  penetrate  the  system 
completely.  This  ability  is  provided  because  the  system 
allows  code  files  to  be  loaded  from  storage  on  magnetic 
tape.  Tape  is  a  standard  medium  for  transferring  data 
between  computer  systems  but  has  no  security  structures 
to  protect  it." 


300 


"Although  the  Burroughs  software  which  transfers  files 
between  tape  and  disk  storage  does  use  complex 
protective  structures,  there  is  nothing  to  prevent  a 
knowledgeable  user  from  imitating  these  structures  and 
creating  arbitrary  code  files  which  the  Burroughs  system 
will  load  and  execute." 

Wilkinson  prerented  a  step-by-step  method  for  penetrating  the 
system.  An  important  step  was  the  validation  of  an  illegal 
compiler,  which  was  accomplished  with  a  program  that  took 
advantage  of  unlabelled  tape  access:  the  program  read  a  tape, 
altered  critical  records  to  validate  the  intended  program  as  a 
compiler,  and  then  wrote  the  altered  information  to  a  second 
tape.  Another  critical  step  involved  copying  the  illegal 
compiler  from  tape  to  disk, 

Imported  File  Vulnerability 

Even  if  a  system  tightly  controls  the  structure  of  locally  created 
magnetic  tapes,  the  threat  remains  that  an  attacker  with  access 
to  another  system  can  create  a  tape  with  any  desired  contents. 
Other  off-line  media,  such  as  removable  disk  packs,  offer  much 
the  same  threat,  as  does  any  network  or  other  data 
communications  facility  that  permits  files  to  be  transferred  into 
the  system. 


Hardware  Vulnerability 

Given  the  vulnerabilities  described  above,  one  may  ask 
whether  any  options  remain  once  an  attempt  is  made  to  exploit 
a  vulnerability.  Is  there  a  final  line  of  defense  in  the 
hardware?  Can  the  hardware  protect  against  faulty  or  suspect 
code  generated  by  a  compiler  or  programmer? 

Single-state  hardware  can  be  designed  to  help  maintain  proper 
separation  of  user  domains  and  help  protect  the  TCB  domain 
(see  Figure  2).  However,  such  hardware  enforcement  relies 
on  registers,  interrupt  vectors,  or  other  control  information 
being  properly  initialized.  If  an  executable  code  sequence 
(whether  compiler-generated  or  assembly-coded)  fails  to 
supply  correct  values  for  base-bound  registers,  memory 
descriptors,  or  code  pointers,  the  hardware  cannot  provide 
meaningful  enforcement.  In  fact,  when  aberrant  control 
information  is  intentionally  supplied,  not  only  is  the  integrity  of 
the  TCB  violated,  but  system  security  is  easily  subverted. 


Figure  2.  Traditional  hardware -enforced  TCB. 


regarding  the  B1  System  Architecture  requirement  of  the 
Trusted  Computer  System  Evaluation  Criteria  [D0D8S],  the 
National  Computer  Security  Center  made  the  following 
general  observation: 

"Hardware  receives  information  from  software,  and 
based  on  that  input  it  determines  what  actions  are 
necessary.  Therefore  hardware  is  as  trusted  as  the 
software  providing  the  input." 

Having  considered  several  vulnerabilities  concerning  execution 
of  code,  it  appears  that  software  controls,  particularly  with 
regard  to  executable  code,  must  play  an  important  part  in  a 
general-purpose,  secure  system. 


A  Software-Enforced  TCB 


The  Unisys  A  Series  is  a  worked  example  of  a  software- 
enforced  TCB.  The  hardware  architecture  supports  only  one 
execution  state,  making  the  system  software  responsible  for 
supporting  privileged  and  non-privileged  modes  of  execution, 
while  protecting  tne  boundaries  of  the  TCB.  Those  parts  of 
the  system  software  that  create  and  maintain  a  self-protecting 
domain  of  execution  include  the  MCP/AS  operating  system, 
compilers,  Message  Control  Systems,  system  libraries,  and 
privileged  programs. 

The  Unisys  A  Series  MCP/AS  with  InfoGuard  security 
enhancements  has  been  evaluated  by  the  National  Computer 
Security  Center  [Fin871  as  meeting  the  requirements  for  Class 
C2  of  the  Trusted  Computer  System  Evaluation  Criteria 
[DoD85].  In  the  process  of  evaluating  the  A  Series  security 
architecture,  the  viability  of  a  software-based,  two-state 
architecture  was  formally  addressed  for  the  first  time.  As  a 
result,  NCSC  issued  the  following  official  interpretation 
[Arc87]: 

"Software-based  architectures  arc  able  to  provide  process 
separation  and  a  two-state  architecture  with  sufficient 
assurance  to  meet  the  B1  level  requirements  for  System 
Architecture.  Simply  because  a  two-state  architecture  is 
provided  and  maintained  primarily  by  software  should 
not  lead  to  the  assumption  of  its  being  less  secure  than 
hardware  in  implementing  security  features.' 

For  a  discussion  of  how  A  Series  meets  the  specific  Class  C2 
and  B1  system  architecture  requirements,  refer  to  the  Final 
Evaluation  Report  [Fin87].  (Although  there  has  been  no 
attempt  to  demonstrate  compliance  with  additional 
architectural  requirements  at  Class  B2  and  above,  the  size  and 
complexity  of  a  software-enforced  TCB  would  increase  the 
difficulty  of  that  task.) 

Unisys  A  Series  is  a  viable,  software-based,  multi-domain 
architecture  because  cooperation  between  compilers  and  the 
operating  system  makes  extensive  software  controls  possible. 
One  of  the  more  critical  aspects  of  TCB  protection  is  the 
control  of  executable  program  code:  only  authorized 
compilers  are  trusted  to  generate  executable  code  files. 

The  nature  of  the  software  controls  employed  by  A  Series  and 
the  integration  of  compilers,  operating  system,  and  hardware  to 
protect  against  potential  threats  to  the  TCB  are  explained 
below. 


Protection  Methods 


The  problem  of  hurdware  enforcement  being  dependent  upon 
software-supplied  control  information  is  not  unique  to  single- 
state  hardware  architectures.  Dual-state  hardware  is  also 
vulnerable  in  this  way.  In  an  official  interpretation  [Arc87] 
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Language  design  and  compiler  implementation  are  both 
critical  to  the  protection  of  a  software-enforced  TCB. 
Languages  generally  available  to  users  must  constrain  data 


manipulation  and  program  flow  control  to  a  level  of 
abstraction  that  cannot  threaten  TCB  integrity.  Manipulation 
and  control  at  the  potent’’  ''  threatening  Tower  level  must  be 
purposely  designed  out  l'  j  '.a:  juages. 

However,  in  order  to  '.mo,  ■*  .  'tain,  and  enhance  a  system, 
we  recognize  the  need  L  r  /..ms  programming  capability. 
Because  languages  for'sytems  programmers  do  provide  access 
to  potentially  subversive  .onstructs,  access  to  the  compilers  for 
such  languages  must  be  carefully  controlled,  More 
importantly,  the  programs  generated  by  such  compilers  must 
be  subject  to  controls. 

Because  TCB  integrity  is  at  stake,  we  cannot  depend  upon  a 
user  who  writes  his  own  compiler  to  adhere  to  safe  principles 
of  language  design  and  compiler  implementation.  For  that 
reason,  the  ability  to  install  a  valid  compiler  on  the  system 
must  be  carefully  controlled. 


Controls  on  Compilers  and  Code  Files 

As  stated  in  the  NCSC  evaluation  of  Unisys  A  Series  [Fin87j: 

"Compilers  in  A  Series  are  expected  to  perform  the  same 
functions  as  compilers  on  any  other  system.  Compilers 
are  expected  to  accurately  implement  the  constructs  of 
their  language.  It  is  the  constructs  within  these  languages 
that  provide  capabilities  to  users." 

Therefore,  a  key  protection  objective  is  to  limit  the  availability 
of  compilers  that  implement  constructs  capable  of  subverting 
security.  Unisys  A  Series  uses  several  methods  to  accomplish 
this  objective. 

Unisys-supplied  compilers  for  A  Series  are  of  two  types:  user- 
language  compilers  and  systems-language  compilers.  User- 
language  compilers  (not  to  be  confused  with  user  -created 
compilers)  implement  languages  designed  with  no  constructs 
capable  of  subverting  security.  Systems-language  compilers 
implement  languages  extended  for  the  purpose  of  system 
software  development;  some  of  the  extended  constructs  are 
considered  "unsafe"  because  they  could  be  used  to  subvert 
security. 

Due  to  the  implications  of  this  language  design  strategy,  the 
controls  necessary  for  the  two  types  of  compilers,  and  for  their 
generated  code  files,  differ  markedly. 

The  Unisys  compilers  are  designed  to  make  the  most 
advantageous  use  of  the  hardware  enforcement  mechanisms 
present  in  the  A  Series  architecture.  The  A  Series  stack 
mechanism  is  well-suited  for  support  of  block-structured 
languages,  but  the  tagged  architecture  of  A  Scries  especially 
enhances  the  software's  ability  to  provide  TCB  protection;  the 
hardware  supports  the  use  of  tag  values  to  strictly  separate 
code  and  control  structures  from  data  [Fin87]. 

-Assembly  Language 

The  most  dangerous  language  capability  that  could  be  offered 
to  programmers  is  assembly  language,  with  its  unlimited 
capacity  for  controlling  and  subverting  a  system.  Unisys 
A  Series  avoids  the  dilemma  of  policing  assembly  language  by 
not  providing  an  assembler,  thus  continuing  a  philosophy 
established  for  the  predecessor  Burroughs  Large  Systems  as  far 
back  as  the  B5000.  Working  under  the  assumption  that 
software-based  systems  allowing  assembly  language 
programming  can  never  be  truly  secure,  Unisys  A  Series 
provides  no  way  to  escape  to  low-level  code  generation, 
requiring  that  programming  be  done  exclusively  in  high-level 
languages. 

As  a  result  of  this  high-level  approach,  compilers  are  trusted  to 
properly  structure  accesses  to  TCB-protected  objects  (see 
Figure  3).  The  compilers  are  responsible  for  building  correct 


references  to  data  items,  ensuring  use  of  valid  descriptors  for 
the  various  kinds  of  files,  and  invoking  the  necessaiy  interfaces 
for  access  to  database  hems.  Although  compilers  are  not 
responsible  for  access  checks  on  objects,  they  are  responsible 
for  emitting  code  that  employs  the  defined  MCP/AS  interfaces 
to  protect  objects  [Fin87]. 


Figure  3.  A  Series  software- enforoed  TCB. 


Benign  User  Languages 


By  design,  the  Unisys-supplied  user  languages  (e.g.,  COBOL, 
ALGOL,  FORTRAN,  Pascal,  RrG)  do  not  contain  constructs 
that  can  be  exploited  to  subvert  security.  In  these  languages, 
the  user  is  allowed  unlimited  access  to  only  the  48  data  bits  in 
some  even-tagged  words.  The  tags  themselves  and  the  data 
bits  of  other  words  can  be  accessed  "only  with  compiler- 
determined  code  sequences  that  precisely  support  the  high- 
level  language  semantics"  [Fin87]. 

Not  only  are  the  user's  code  and  data  strictly  separated,  but  the 
compiler  provides  access  to  only  those  MCP/AS  interfaces 
intended  for  use  by  ordinary  users  [Fin87j.  Compilers  control 
the  calling  sequence  and  parameter  evaluation  code,  thus 
ensuring  that  a  user  is  never  given  unconstrained  access  to 
MCP/ASprocedures.  Therefore,  software  restrictions  are  not 
required  for  the  use  of  user-language  compilers  or  the  code 
files  they  generate.  Because  the  entire  A  Series  system  is 
geared  toward  high-level  language  programming,  much  of  the 
system  software,  including  the  compilers,  is  written  in  user 
languages  (primarily  ALGOL). 

Controlled  Systems  Programming  Languages 

The  systems  programming  languages  (i.e.,  DCALGOL 
DMALGOL  NtWr)  on  A  Series  are  extended  dialects  of 
ALGOL  DCALGOL  includes  some  system  control  and  data 
communications  interfaces.  DMALGOL  is  further  extended  to 
include  special  constructs  for  database-management  and 
transaction-processing  software.  NEWP  includes  low-level 
constructs  for  I/O  control,  memory  and  processor 
management,  and  other  operating  system  functions.  These 
systems  programming  languages  may  also  be  used  to  write 
ordinary  executable  programs  composed  only  of  safe 
constructs. 
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Using  unsafe  NEWP  constructs,  a  programmer  can  manipulate 
all  52  bits  of  a  word,  including  tne  tag.  Nevertheless,  these 
systems  programming  languages  do  not  facilitate  generation  of 
completely  arbitrary  code  sequences.  Even  at  the  level  of 
unsafe  constructs,  the  compiler  imposes  conformance  with 
appropriate  abstractions  (e.g„  descriptor  semantics). 


Because  the  systems-language  compilers  for  DCALGOL, 
DMALGOL,  and  NEWP  offer  these  additional  interfaces  for 
system  software  implementation,  it  is  possible  to  write 
programs  that  subvert  security.  However,  not  all  the  code  files 
generated  by  systems-language  compilers  are  dangerous.  To 
avoid  placing  overly  stringent  controls  on  such  code  files,  three 
mechanisms  are  used  to  identify,  authorize,  and  control 
potentially  dangerous  programs. 

1.  DCALGOL  code  files  are  dangerous  only  in  the 

sense  that  they  may  attempt  to  access  system 
control  interfaces  in  MCP/AS.  However,  those 
MCP/AS  entry  points  protect  themselves  by 
requiring  that  the  calling  process  be  privileged  A 
process  is  privileged  only  if  executed  by  a  privileged 
user  or  if  its  associated  code  file  was  marked 
privileged  via  the  system  command  PP  (Privileged 
Program)  or  by  virtue  of  being  a  properly  defined 
Message  Control  System  (MCS).  A  compiler 
cannot  create  a  privileged  code  file,  and  only  a 
trusted  user  can  perform  the  PP  command. 
Creation  of  an  MCS  also  requires  trusted  user 
intervention. 

2.  NEWP  or  DMALGOL  code  files  that  use  unsafe 

constructs  are  marked  non-executable  when  created 
by  the  compiler.  To  enable  execution  of  such  a 
code  file,  a  trusted  user  must  perform  the  system 
command  XP  (executable  Program)  or  SL  (System 
Library). 

3.  Certain  unsafe.  NEWP  code  files  can  be  executed 

only  via  the  system  command  CM  (Change  MCP), 
which  is  available  only  to  trusted  users. 

In  each  of  the  three  cases  described  above,  potentially 
dangerous  code  files  cannot  be  executed  without  an  extension 
of  trust  to  the  programs  using  those  interfaces.  However,  the 
greater  the  number  of  users  trusted  to  perform  such  enabling 
actions,  the  greater  the  vulnerability  to  human  error  or 
malfeasance. 

InfoGuard  on  an  A  Series  system  can  erect  multiple  security 
barriers  to  control  the  introduction  of  unsafe  code  to  the 
system.  Even  though  a  single  barrier  would  normally  suffice, 
multiple  barriers  provide  additional  protection  in  the  event 
that  trust  (of  programs  or  people)  is  misplaced  or  violated. 

On  a  non-InfoGuard  A  Series  system,  there  are  two  classes  of 
users:  privileged  and  non-privileged.  Normal  DAC 
mechanisms  can  make  systems-language  compilers  jnaccessible 
to  unauthorized  users.  However,  a  privileged  user  is  trusted  to 
bypass  file  security  checks  and  to  exercise  system  control. 
Therefore,  privileged  users  can  access  systems-language 
compilers,  compile  unsafe  code  files,  and  install  (or  make 
executable)  suen  code  files. 

On  a  system  using  InfoGuard,  a  security  administrator  role  can 
be  defined,  thus  removing  security-critical  control  functions 
(e.g.,  PP,  XP,  SL)  from  the  privileged  users.  Even  though  a 
privileged  user  can  still  access  systems-language  compilers  to 
create  unsafe  code  files,  he  is  unable  to  execute  or  otherwise 
install  those  code  files  because  the  necessary  control  functions 
can  only  be  performed  by  a  security  administrator  [SAG87]. 


FILEKIND  Controls 

In  the  control  of  compilers  and  code  files,  MCP/AS  uses  the 
FILEKIND  attribute  as  an  important  discriminator. 
FII  EKIND  is  an  attribute  of  a  disk  file  that  denotes  its 
purpose  and,  to  some  extent,  its  internal  structure.  Subranges 
of  the  FILEKIND  values  are  reserved  for  special  purposes: 
system  files  (such  as  disk  directories),  code  files,  program 
source  files,  and  data  files. 

Unique  FILEKINDs  are  provided  for  programming  languages 
and  dialects,  as  well  as  textual  data,  so  that  the  editing  format 
and  appropriate  compiler  car  be  inferred.  For  example,  the 
value  ALGOLSYMBOL  indicates  program  source  written  in 
ALGOL,  while  the  value  PASCALCODE  indicates  a  code  file 
created  by  the  Pascal  compiler.  COMPILERCODEFILE  is  a 
special  value  in  the  system-file  subrange  that  indicates  an 
authorized  compiler. 

The  assignment  of  a  FILEKIND  value  to  a  file  is  controlled  by 
MCP/AS.  Only  authorized  system  software  may  assign  values 
in  the  system-file  subrange,  including  the 
COMPILERCODEFILE  value.  Only  compilers  may  assign 
values  in  the  code-file  subrange  (thereby  creating  code).  Users 
are  allowed  to  assign  values  only  in  the  program-source  or 
data-file  subranges.  A  user  can  change  the  FILEKIND  of  a 
code  file  to  an  unprotected  (e.g.,  data-file)  value  only  if  the  file, 
is  not  currently  being  executed  by  any  process. 


Trust  and  Authorization  of  Compilers 

To  prevent  the  user  from  generating  arbitrary  code  sequences, 
the  ability  to  create  code  is  reserved  to  authorized  compilers 
on  A  Series.  An  authorized  compiler  is  recognized  by 
MCP/AS  according  to  its  FILEKIND.  Although  this  approach 
eliminates  concerns  about  the  code  integrity  of  ordinary 
programs,  it  requires  that  a  great  deal  of  trust  be  placed  in  the 
compilers.  For  this  reason,  the  ability  to  authorize  a  compiler 
must  be  carefully  controlled. 

Trusted-Compilers  Enforce .Eralsciion  Rules 

In  their  role  us  emitters  of  code,  compilers  function  at  a  low 
level  of  abstraction  -■  next  to  the  hardware.  Because  the 

n rammer  has  no  access  to  the  machine  language  of  the 
tries  processor,  the  compilers  can  play  an  important  role  in 
ensuring  the  integrity  of  the  system.  However,  for  software 
controls  to  be  adequately  enforced  on  single-state  hardware, 
compilers  must  complement  the  hardware  reliably. 

When  a  compiler  is  granted  the  privilege  to  create  executable 
code  files,  it  is  trusted  to  rigorously  enforce  a  number  of 
protection  rules.  A  few  examples  of  those  rules  are 
summarized  below: 

Consistent  semantics  for  data  abstractions: 

Emit  valid  object  addresses;  emit  code  sequences 
appropriate  for  manipulating  the  type  of  object  at 
each  address;  enforce  type  matching  on  all 
procedure  parameters  and  results. 

Benign  interfaces: 

Employ  defined  interfaces  for  construction  and 
destruction  of  memory  segments;  use  only  benign 
code  sequences  in  creating  or  operating  upon 
references.  (Safe,  properly;  constructed,  A  Series 
code  is  characterized  not  juat  by  the  absence  of 
particular  instructions  but  also  by  the  use  of  some 
potentially  harmful  instructions  only  in  valid  ways.) 

Referential  integrity: 

Avoid  dangling  references  by  refusing  to  store 
reference  words  in  places  where  they  might  outlast 
their  referents  and  by  storing  references  only  where 
they  can  be  found  systematically  if  necessary. 
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Controlled  branching: 

Emit  valid  branch  addresses;  properly  limit  the 
range  of  dynamic  code  selections  (e.g.,  CASE  or 
SWITCH  statements). 

Structural  containment: 

Limit  the  potential  impact  of  one  process  on 
another  hy  allowing  a  process  to  refer  only  to  other 
processes  that  are  structurally  related  to  it,  either 
ancestors  (including  self)  or  declared  task  variables 
within  its  own  addressing  scope;  constrain 
references  to  objects  according  to  the  structure  of 
the  environment. 

In  generul,  a  compiler  is  expected  to  conform  to  its  language 
specification  and  to  adhere  to  architectural  principles  that 
enable  the  hardware  to  preserve  TCB  integrity. 

Compiler  Authorization 

In  order  to  authorize  a  compiler,  the  system  command  MC 
(Make  Compiler)  must  be  executed  to  request  that  MCP/AS 
change  the  FILEK1ND  of  an  existing  code  file  to 
COMPILERCODEFILE.  The  MC  command  may  only  be 
executed  by  a  trusted  user.  In  a  non-InfoGuard  system,  that 
trust  is  extended  to  operators  and  privileged  users.  However, 
in  an  InfoGuard  system,  the  circle  of  trust  can  be  considerably 
smaller;  when  the  security  administrator  role  is  defined,  the 
MC  command  may  be  executed  only  by  a  security 
administrator  [SAG87], 

Due  to  the  FILEK1ND  controls  enforced  by  MCP/AS,  an 
ordinary  user  program  is  prevented  from  creating  a  code  file. 
Furthermore,  a  user  program  residing  on  the  system  cannot 
become  a  compiler  without  the  approval  or  cooperation  of  an 
appropriately  authorized  person.  However,  to  guard  against 
’I  rojan  Horse  attacks,  an  authorized  person  must  be  cautious 
about  executing  programs  that  might  attempt  to  use  a 
programmatic  interface  to  authorize  a  compiler.  Only 
DCALGOL  and  NEWP  provide  access  to  such  a  programmatic 
interface,  but  successful  use  of  that  interface  requires  that  trust 
be  extended  to  the  program  either  explicitly;  via  the  PP  system 
command  or  implicitly  when  a  property  privileged  person  (e.g., 
the  security  administrator)  executes  the  program. 


No  Code  Modification 

Bv  preventing  a  user  from  creating  or  importing  a  compiler, 
we  are  assured  that  the  user  cannot  directly  create  a  code  file. 
However,  we  must  also  be  sure  that  a  user  cannot  arbitrarily 
modify  code  whether  it  resides  in  memory  or  in  an  existing 
code  file  on  disk.  The  Unisys  A  Series  systems  rely  upon  a 
combination  of  hardware  and  software  mechanisms  to  prevent 
a  user  from  modifying  code. 


Process  Stack 


Code  Segment 
Dictionary 


Seta  words 


Figure  4.  Tags  separate  code  from  data. 


Software  mechanisms  prevent  modification  of  code  stored  on 
disk  in  u  code  file.  Tags  are  rarely  stored  with  information  on 
disk,  except  for  the  system-controlled  overlay  file  used  by 
MCP/AS  during  memory  management  operations.  There  is  no 
opportunity  for  a  user  to  tag  data  in  a  file  so  that  it  would 
appear  to  be  code.  For  each  code  file  being  executed, 
MCP/AS  creates  a  special  stack,  the  Code  Segment 
Dictionary,  that  contains  descriptors  to  the  code  file's  code 
segments  and  read-only  data  segments  (see  Figure  4);  multiple 
processes  executing  the  same  code  file  can  Be  linked  to  the 
same  Code  Segment  Dictionary.  When  information  is  read 
from  a  disk  file  into  memory,  N'-’  7/AS  relies  upon  the 
FILEKIND  and  segment  descriptor  to  assign  appropriate  tags 
to  the  information  during  the  read  operation  [Fins'1]. 


The  fact  that  existing  code  files  cannot  be  modified  on  an 
A  Series  system  provides  additional  protection  against  viruses 
and  Trojan  Horses.  When  compiler  validation  is  propeily 
controlled,  viruses  cannot  be  injected  into  existing  code  files, 
and  Trojan  Horses  cannot  be  added  to  existing  code  files.  In 
short,  virus  propagation  is  prevented. 


The  tagged  architecture  of  A  Series  makes  strict  separation  of 
■.ode  and  data  possible  (see  Figure  4).  Code  words  and  code 
pointers  in  memory  are  protected  by  odd  tag  values,  meaning 
they  cannot  be  fetched  or  stored  by  the  hardware  instructions 
that  normally  operate  upon  data.  The  user  is  thereby 
prevented  from  reading  or  writing  code  words  in  memory. 
Because  the  hardware  executes  only  words  with  odd  tags 
(specifically,  tag-3  words)  and  the  user  is  not  able  to 
manipulate  code  pointers  (tag-3  and  tag-7  words),  there  is  no 
way  to  execute  data  as  code. 


The  FILEKIND  controls  enforced  by  MCP/AS  are  also 
eff.’ciive  in  preventing  a  user  from  updating  or  rewriting  an 
existing  code  file  on  disk.  MCP/AS  ensures  that  only 
programs  with  a  FILEKIND  of  COMPILERCODEFILE  are 
allowed  to  create  or  modify  a  code  file  (see  Figure  5).  Any 
attempt  by  a  u  er  program  to  assign  a  FILEKIND  value  of 
code  is  rejected.  A  user  program  is  allowed  to  read  a  code  file, 
but  if  it  attempts  to  modify  an  existing  code  file,  the  write 
operation  is  aborted  with  an  error. 
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Figure  5.  Code  file  protection  on  A  Series. 


Disk  Files  on  Tape 

To  preserve  the  contents  and  attributes  of  disk  files  being 
stored  or  transported  on  magnetic  tape,  MCP/AS  uses  a 
special  tape  format  called  a  "Library  Maintenance'1  tape,  which 
is  distinguished  bv  a  field  in  the  volume  label;  these  tapes 
contain  images  of  disk  files  including  their  defining  header 
records.  Only  the  library-maintenance  utility  of  MCP/AS  can 
create  such  tapes  or  transfer  disk  files  to  or  from  tapes  while 
preserving  such  attributes  as  FILEKIND;  that  utility  rejects 
attempts  to  read  from  ordinary  data  tapes. 

In  ordinary  use,  all  tapes  are  written  with  standard  labels, 
which  are  used  for  automatic  assignment  of  tape  files  to 
processes,  (The  tape  label  convention  also  prevents  reading 
any  information  past  the  nominal  end  of  tape,  preventing 
access  to  residual  data  that  might  follow  the  labelled  contents 
of  the  tape.) 

A  program  that  reads  and  writes  “unlabelled"  tapes  could  both 
bypass  and  forge  tape  labels  and  disk-file  header  images. 
Indeed,  the  Wilkinson  penetration  used  just  this  technique, 
achieving  validation  of  an  illegal  compiler  by  changing  the 
FILEKIND  in  the  tape  file  header  to  COMPILERCODEF1LE 
via  unlabelled  tape  access  fWilSl).  An  InfoGuard  system  can 
be  configured  to  meet  this  threat  by  requiring  operaior 
intervention  to  assign  any  tape  to  a  process  for  unlabelled 
access  [SAG87], 


Code  File  Importation  Restrictions 

While  we  have  explained  how  compiler  validation  for  programs 
residing  on  an  A  Series  system  can  be  carefully  controlled,  we 
must  still  address  the  issue  of  illegal  compilers  (or  other  code 
files)  introduced  from  off-line  storage  or  from  another  host 
system.  Rather  than  detecting  which  programs  actually 
threaten  system  integrity,  A  Series  software  provides  the 
means  to  control  imported  programs,  thus  helping  the  security 
administrator  enforce  security  policy;  the  security 
administrator  then  uses  his  own  judgment  to  decide  which 
imported  programs  to  release  from  controls. 


importation  from  Storage  Media 

Wilkinson  [W1181]  introduced  an  illegal  compiler  to  the  system 
by  copying  it  from  an  altered  tape  to  disk.  On  an  A  Series 
fnfoGucrd  system,  there  are  two  barriers  to  the  introduction  of 
dangerous  code  files  from  tape  [SAG87): 

1.  The  security  administrator  can  set  the  system  security 

option  TAPECHECK  to  the  value  AUTOMATIC, 
requiring  that  tape  labels  exactly  match  an  existing 
entry  in  the  tape  volume  directory,  a  central 
database  maintained  on  disk  by  MCP/AS,  before  a 
copy  request  involving  that  tape  can  proceed.  If 
there  is  no  matching  entry  in  the  tape  volume 
directory,  the  copy  request  is  blocked,  requiring 
operator  action. 

2.  Furthermore,  the  security  administrator  can  restrict 

tape  units  so  that  any  code  files  copied  from  those 
units  arc  marked  non-executable,  no  matter  how 
privileged  the  user  or  process  performing  the  copy. 

In  fact,  the  second  barrier,  the  ability  to  designate  untrusted 
file  sources  and  automatically  restrict  any  files  from  those 
sources,  is  a  basic  feature  of  the  Mark  3.7  release  of  the 
A  Series  operating  system  and  does  not  require  InfoGuard. 
(Concentrating  the  restrictive  capabilities  under  security 
administrator  control,  rather  than  trusted  u.vr  control,  does 
require  InfoGuard.)  The  restricted  designation  can  be  applied 
to  tape  units,  disk  units,  tape  volumes  (reels),  removable  disk 
packs,  remote  (network)  hosts,  and  even  to  individual  files.  In 
effect,  these  restrictions  define  the  logical  security  perimeter  of 
a  system  (see  Figure  6). 
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Figure  6.  Code  file  Importation  restrictions. 


Once  a  code  file  has  been  marked  non-executable  because  it 
originated  from  an  untrusted  source,  only  a  system 
administrator  can  remove  the  restriction  from  that  program 
and  make  it  executable  again.  Copying  the  restricted  file  to 
another  unit  or  to  another  storage  medium  does  not  remove 
the  restriction. 
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Any  comprehensive  security  policy  for  tape  files  requires 
physical  security  on  the  tape  volumes.  InfoGuard  provides 
tools  that  can  be  combined  with  sound  operational  procedures 
to  effect  substantial  barriers  against  abuse  via  tapes  or  other 
media. 

After  attacking  a  Burroughs  system  on  several  fronts, 
Wilkinson  and  nis  colleagues  concluded  that  "a  B6700  system 
which  disallowed  the  loading  of  code  files  from  demountable 
tape  or  disk  pack  would  be  very  difficult  to  penetrate."  The 
Unisys  A  Series  systems  that  evolved  from  the  Burroughs 
B6700  have  responded  to  this  challenge  --  the  ability  to  restrict 
code  file  importation  greatly  increases  A  Series  resistance  to 
penetration,  The  robustness  of  the  Unisys  A  Series  security 
architecture  is  further  enhanced  by  the  InfoGuard  features  that 
support  a  tape  security  subsystem  and  a  security  administrator 
role. 

Importation  across  Network 

By  prudent  use  of  code  file  importation  restrictions,  a  system 
administrator  can  erect  a  barrier  against  Trojan  Horse 
programs  that  might  be  transported  via  tape  or  removable 
pack.  In  a  similar  manner,  restrictions  can  be  placed  on  code 
tiles  imported  across  a  network. 

When  the  system  security  option  HOSTSRESTRICTED  is  set, 
any  code  file  copied  onto  an  A  Series  system  from  a  remote 
host  in  the  network  is  automatically  marked  as  non-executable 
[SAG87].  Again,  only  a  system  administrator  can  remove  that 
restriction  from  a  program  to  make  it  executable. 

If  a  user  were  to  breach  security  on  one  host  in  a  network, 
somehow  obtain  a  valid  use rcode /password  for  each  remote 
host,  and  copy  his  Trojan  Horse  program  to  each  remote  host, 
then  those  hosts  that  had  the  HOSTSRESTRICTED  option  set 
would  be  protected  by  MCP/AS.  On  the  protected  hosts, 
MCP/AS  would  mark  the  code  file  as  non-executable, 
effectively  containing  the  Trojan  Horse  until  the  system 
administrator  had  the  opportunity  to  scrutinize  the  program 
and  take  appropriate  action. 

Thus,  the  HOSTSRESTRICTED  option  enables  a  svstern 
administrator  to  erect  a  barrier  against  proliferation  of  Trojan 
Horse  and  virus  programs  across  a  network.  This  option  can 
severely  limit  the  ability  of  a  virus  to  propagate  beyond  its 
original  host. 


Protection  of  Installed  Software 

The  integrity  of  the  TCB  code  is  protected  by  the  same 
mechanisms  that  prevent  unauthorized  modification  or 
introduction  of  other  code  files.  The  TCB  domain  is  further 
protected  by  the  fact  that  installing  or  changing  any  part  of  the 
TCB  software  requires  execution  of  privileged  commands  by 
trusted  users.  On  an  InfoGuard  system  with  the  security 
administrator  role  defined,  those  privileged  commands  are 
available  only  to  a  security  administrator. 

The  A  Series  TCB  software  includes  MCP/AS,  system 
libraries,  compilers,  Message  Control  Systems,  and  privileged 
programs.  The  privileged  methods  for  installing  or  changing 
these  software  components  are  summarized  below  [SAG87]: 

1.  MCP/AS  cannot  be  installed  or  changed  except  by  a 
system  administrator  with  physical  access  to  the 
system.  A  new  MCP  must  first  be  compiled  by  the 
NEWP  compiler,  which  automatically  marks  the 
newly  comptled  code  file  with  a  unique,  non¬ 
executable  FILi  KIND.  Then,  the  system 
command  CM  (Change  MCP)  must  be  executed  to 
install  the  code  file,  requiring  total  interruption 
(HALT)  and  restart  (LOAD)  of  the  system. 


2.  System  libraries  must  be  installed  with  the  system 

command  SL  (System  Library),  a  command  that 
can  be  restricted  to  the  security  administrator  under 
InfoGuard. 

3.  Compilers  must  be  validated  with  the  system 

command  MC  (Make  Compiler),  a  command  that 
can  he  restricted  to  the  security  administrator  under 
InfoGuard. 

4.  Each  Message  Control  System  (MCS)  must  be  named 

in  the  data  communications  netw  rk  definition 
(known  as  Datacominfo)  for  that  system.  A  new 
Datacominfo  must  be  installed  with  the  system 
command  ID  (Initialize  Datacom).  The  ID 
command  and  the  privilege  to  update  the  active 
Datacominfo  can  both  be  restricted  to  the  security 
administrator  under  InfoGuard. 

5.  Portions  of  the  data-management  and  transaction- 

processing  software  that  use  unsafe  DMALGOL 
constructs  must  be  made  executable  with  the  system 
command  XP  (executable  Program),  a  command 
that  can  be  restricted  to  the  security  administrator 
under  InfoGuard. 

6.  Privileged  programs  must  be  marked  as  privileged 

with  the  system  command  PP  (Privileged  Program), 
a  command  that  can  be  restricted  to  the  security 
administrator  under  InfoGuard. 

Enforcement  of  the  many  software  controls  on  A  Series 
enables  greater  assurance  than  mere  procedural  controls  could 
provide.  By  virtue  of  the  fact  that  the  software  controls  are 
well-integrated  in  the  system  and  mutually  reinforcing,  they 
provide  multiple  barriers  to  penetration  or  compromise. 


Summai^  and  Conclusions 


In  exploring  the  concept  of  a  software-based  security 
architecture,  several  vulnerabilities  relating  to  program  code 
were  considered,  and  methods  of  program  containment  that 
protect  against  those  vulnerabilities  were  presented  in  the 
context  of  the  Unisys  A  Series  as  a  worked  example.  The 
threat  of  assembly  language  programming  is  avoided  by 
providing  no  assembler  and  no  escape  to  iow-level  code 
generation.  Coercion  of  valid  compilers  is  prevented  by 
language  design  that  provides  benign  user  languages,  while 
relying  upon  compiler  implementation  to  identify  "unsafe" 
programs  written  in  systems  programming  languages  so  the 
operating  system  can  enforce  controls  on  those  programs. 

The  software  architecture  of  A  Series  requires  and  provides 
for  careful  controls  on  compilers  and  code  files.  Through 
FILEKIND  controls,  the  operating  system  ensures  that  code 
files  may  be  created  or  modified  only  by  authorized  compilers; 
only  a  system  administrator  can  authorize  a  compiler.  Through 
use  of  hardware-enforced  tags  and  segments,  code  in  memory 
is  protected  from  modification,  and  execution  of  data  as  code  is 
prohibited.  Code  files  exist  on  tape  only  in  special,  protected 
formats.  Importation  of  dangerous  code  files  or  illegal 
compilers  from  untrusted  sources  such  as  tape  or  remote  hosts 
can  be  restricted,  with  enforcement  by  the  operating  system. 
In  combination,  these  controls  provide  an  unusually  strong 
defense  against  the  introduction  of  viruses  or  Trojan  Horses 
into  existing  code  files,  raising  multiple  barriers  against  virus 
propagation. 

Cooperation  between  compilers  and  the  operating  system  in 
adhering  to  architectural  principles  can  significantly  enhance 
the  protection  afforded  by  single-state  hardware,  with  system 
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software  supporting  privileged  and  non-privileged  operations,  a 
multi-domain  security  architecture  is  achieved,  Together,  the 
operating  system,  compilers,  and  hardware  are  able  to  protect 
the  integrity  of  the  TCB. 
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Appendix 


To  illustrate  the  A  Series  concept  of  process  domains,  we 
consider  the  situation  where  a  process  invokes  an  entry  point 
of  an  external  program.  The  A  Series  system  allows  binding  of 
external  program  references  to  be  deferred  until  execution- 
time  through  use  of  the  "library”  mechanism;  in  this  context, 
the  term  "library"  refers  to  a  process  that  exports  entry  points 
(procedures)  for  dynamic  unking  by  MCP/AS  to  client 
processes  [Fin87],  Figure  7  shows  how  the  different  process 
domains  are  structured  for  the  following  ALGOL  program 
text: 


Client  program: 
begin  %  outer  block 

PROCEDURE  Q  (K,  F) ; 
VALUE  K; 

INTEGER  K; 

ARRAY  F  [0] ; 
LIBRARY  L? 

ARRAY  A  [0:4]; 

PROCEDURE  P; 

BEGIN 

INTEGER  I) 

Q  bl  A); 

END  P; 

P;’ 

END. 


Library  program: 

BEGIN 

ARRAY  D  [014] ; 

PROCEDURE  Q  (K,  F) ; 
VALUE  K; 

INTEGER  K; 

ARRAY  F  [O] ; 

BEGIN 

F[K]‘l-  D[K] ; 

END  Q; 

EXPORT  Q; 

FREEZE. . . ;  %  as  library 

END. ' 


Procedure  )  5 
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As  each  block  or  procedure  of  a  program  is  invoked,  a  new 
“activation  record1'  is  built  on  the  stack;  an  activation  record 
contains  the  control  words  and  data  that  define  the  state  of  a 
procedure  once  it  has  been  activated  (invoked).  For  each 
declaration  in  a  procedure,  an  appropriate  stack  item  is 
allocated  in  its  activation  record.  In  Figure  7,  the  activation 
records  for  the  client  process  are  delineated  with  brackets  and 
annotated  "Outer  Block",  "Procedure  P",  and  "Procedure  Q". 

The  Outer  Block  of  the  client  program  declares  Q,  A,  and  P. 
Because  Q  refers  to  a  procedural  entry  point  declared  in  an 
external  library,  the  client  stack  item  for  Q  is  a  tag-1  reference 
to  the  actual  tag-7  entry  point  Q  in  the  library  stack.  Array  A 
of  the  client  is  allocated  a  descriptor  to  the  data  segment  for 
that  array  in  memory.  The  client's  local  Procedure  P  is 
allocated  a  tag-7  entry  point  word. 

When  Procedure  P  is  invoked  from  the  Outer  Block  of  the 
client  program,  the  activation  record  for  P  includes  a  tag-0  data 
word  for  us  local  Integer  I.  P  then  invokes  Q,  the  library  entry 
point,  passing  the  value  7  to  Q's  formal  parameter  K  and 
passing  the  Array  A  to  Q's  formal  parameter  F. 

To  show  the  domain  relationships  between  the  two  stacks,  the 
execution  domain  of  the  library  entry  point  is  depicted  by 
shading  the  relevant  activation  records  (Procedure  Q  on  the 
client  stack  plus  the  outer  block  of  the  library  stack)  and  the 
data  segment  (Array  D)  belonging  to  the  library.  Even  though 
Procedure  Q  executes  on  the  client  stack,  its  domain  does  not 
directly  include  items  in  the  client's  other  activation  records. 
However,  Q  can  reference  Array  A  of  the  client  indirectly 
through  the  formal  parameter  Array  F  because  A  was  passed 
as  the  actual  parameter  to  F.  Array  A  is  shaded  differently  to 
indicate  that  it  is  shared  by  the  client  process  and  the  library 
entry  point  Q. 

To  summarize,  the  execution  domain  of  a  procedure  is  defined 
by  its  addressing  environment,  which  includes  the  procedure's 
own  activation  record,  all  activation  records  global  to  the 
procedure  in  its  declared  scope,  plus  any  items  passed  to  the 
proce  Jure  as  parameters.  In  addition,  the  domain  is  extended 
to  include  any  data  segments  (arrays)  referenced  by  items  in 
this  addressing  environment. 

In  a  similar  manner,  a  process  can  invoke  entry  points  of  the 
operating  system.  An  MCP  procedure  can  execute  on  top  of  a 
user's  process  stack  and  access  the  user  domain  through 
parameters,  but  the  MCP  domain  is  protected  from  any  direct 
access  by  the  user's  procedures.  While  executing  on  the  user's 
process  stack,  the  MCP  procedure  itself  still  has  access  to  data 
in  the  operating  system  domain. 
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ABSTRACT 

This  paper  discusses  access  mediation  approaches  for  a 
class  of  computer  architectures  termed  server-oriented 
systems.  The  focus  is  on  the  architectural  issues  in¬ 
volved  in  designing  a  server-based  system  that  remains 
faithful  to  the  concept  of  a  reference  monitor.  In  addi¬ 
tion  to  general  concepts  and  concerns,  two  specific  arch¬ 
itectures  are  examined. 


1.  INTRODUCTION 

Over  the  pest  several  years  Trusted  Information 
Systems,  Inc.  (TIS)  has  been  involved  in  analyzing  a 
number  of  computer  systems  to  determine,  in  each  case, 
the  feasibility  of  evolving  the  system  to  a  B2  or  B3 
trusted  system  as  defined  by  the  DoD  Trusted  Computer 
System  Evaluation  Criteria  (TCSEC)  (11.  All  of  these 
systems  are  designed  to  operate  on  a  collection  of  multi¬ 
processors,  usually  a  small  set  of  tightly  coupled  proces¬ 
sors  with  shared  memory,  Although  diverse  in  size, 
complexity,  and  targeted  application  arena,  each  operat¬ 
ing  system  exhibits  a  similar  set  of  organizational  char¬ 
acteristics  that  strongly  influenced  its  potential  to  evolve 
to  a  trusted  system.  These  characteristics  center  around 
an  object-oriented  design  philosophy  where  system  re¬ 
sources  are  presented  as  a  set  of  abstract  typed  objects 
that  may  be  manipulated  via  a  set  of  predefined  opera¬ 
tions.  The  set  of  operations  for  a  particular  object  type 
are  collected  together  into  a  single,  independent  object- 
type  manager  or  server.  Hence,  these  systems  are  char¬ 
acterized  as  server-oriented  systems. 

Generally,  the  server-oriented  systems  that  TIS  has 
examined  are  partitioned  into  three  progressively  more 
abstract  layers  that  typically  have  a  direct  correspon¬ 
dence  to  privilege  layers  provided  by  the  hard¬ 
ware/software.  The  most  privileged  layer  is  the  kernel , 
which  directly  manages  the  physical  machine  providing  a 
limited  view  of  the  system  resources.  The  kernel  encap¬ 
sulates  the  physical  machine  providing  for  resource  utili¬ 
zation  via  a  well-defined  set  of  primitive  operations. 
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The  second  layer  is  the  collection  of  system  servers , 
each  managing  a  particular  type  of  object  constructed 
from  the  kernel-provided  primitives.  Examples  of  typi¬ 
cal  servers  include  file,  device,  ana  mail  servers.  The 
consumers  of  a  server’s  services,  i.e.,  the  clients,  consti¬ 
tute  the  third  layer  of  server-oriented  systems.  Servers 
can  also  be  clients  when  the  services  of  another  server 
are  required. 

We  have  found  that  many  server-oriented  systems, 
though  not  initially  designed  as  trusted  systems,  have 
potential  for  evolving  to  B2  or  B3  systems.  The  primary 
rationale  for  this  conclusion  is  that  the  inherently  layered 
structure  of  a  server-oriented  design  philosophy  results  in 
a  system  architecture  that  incorporates  many  of  the 
fundamental  architectural  traits  required  for  a  highly 
trusted  system  (e.g.,  modularity,  least  privilege,  abstrac¬ 
tion  and  data  hiding).  The  primary  task  in  evolving 
these  systems  to  trusted  systems  has  proven  to  be  the  in¬ 
clusion  of  a  complete  und  comprehensive  reference 
validation  mechanism  that  meets  the  criteria  of  a  refer¬ 
ence  monitor  (see  (2J)  while  maintaining  the  systems’ 
strong  architectural  traits. 

In  this  paper,  experiences  with  developing  trusted 
versions  of  two  server-oriented  systems  are  discussed. 
The  first  system,  Aspen,  is  a  prototype  system  developed 
by  Amdahl  Corporation  to  run  on  Amdahl  470s,  580s, 
and  other  IBM  370-compatible  system  architectures  [3], 
Aspen's  design  is  strongly  influenced  by  the  server-ori¬ 
ented  philosophy  with  most  system  resources  only  acces¬ 
sible  via  object-type  servers.  The  second  system  ex¬ 
amined  is  Mach,  an  operating  system  kernel  being  de¬ 
veloped  at  Camegie-Melloti  University  (CMU)  [4], 
Mach  is  designed  to  be  transportable  across  a  broad 
range  of  computer  architectures,  from  monolithic  proces¬ 
sors  to  highly  parallel  architectures.  Though  Mach  is 
currently  only  a  kernel,  TIS  is  developing  a  prototype 
trusted  version  (called  TMach)  based  upon  the  server- 
oriented  design  of  Mach’s  precursor  system,  Accent[5], 

The  experienced  gained  from  examining  Aspen, 
Mach,  and  other  server-oriented  systems  has  led  to  the 
identification  of  several  general  approaches  for  access 
mediation  within  server-oriented  systems.  The  remainder 
of  this  paper  will  discuss  these  general  approaches  and 
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the  specific  solutions  used  in  the  trusted  designs  of  both 
Aspen  and  Mach. 


2.  ESSENTIAL  SYSTEM  CHARACTERISTICS 

Several  architectural  characteristics,  which  server- 
oriented  systems  tend  to  exhibit,  play  a  central  role  in 
determining  access  mediation  approaches  for  such  sys¬ 
tems,  These  characteristics  result  in  an  environment  in 
which  servers  and  clients  can  operate  in  a  controlled  and 
unambiguous  fashion.  The  architectural  characteristics 
that  are  most  central  in  the  design  of  a  trusted  server- 
oriented  system  include: 

(a)  Protected  and  Isolated  Execution  Domains 

Servers  and  clients  can  expect  to  execute  in  an  en¬ 
vironment  free  from  interference  by  other  servers 
and  clients.  Typically,  this  is  provided  through 
address  space  isolation  and  memory  protection. 
For  example,  servers  and  clients  can  both  execute 
as  distinct  processes  within  the  same  hardware 
privilege  state.  However,  we  have  seen  other 
methods  for  providing  isolated  execution  domains 
that  are  also  adequate.  In  Aspen,  for  example, 
software  engineering  principles  (e.g.,  modularity) 
are  used  to  provide  separation  among  trusted 
server  domains  while  hardware  protection  mech¬ 
anisms  are  used  to  separate  untrusted  server  and 
client  domains  from  other  untrusted  and  trusted 
server  and  client  domains. 

(b)  Resource  Isolation 

A  fundamental  concept  of  server-oriented  systems 
is  that  all  manipulation  of  a  particular  object  is 
controlled  via  the  server  responsible  for  that  ob¬ 
ject-type.  As  such,  primitive  resources  used  by  a 
server  to  create  more  abstract  objects  must  be 
isolated  from  other  entities  in  the  system.  In  a 
strict  server-oriented  paradigm,  the  resources  man¬ 
aged  by  one  server  should  only  be  accessible  by 
clients  and  other  servers  (either  trusted  or  untrust¬ 
ed)  via  the  managing  server. 

(c)  Controlled  Inter-Domain  Communication 

In  order  for  clients  to  request  the  services  of  a 
server,  a  communication  mechanism  must  exijt 
among  clients  and  servers.  In  order  to  maintain 
separation  and  isolation  between  server  and  client 
domains,  this  communication  mechanism  must  be 
controlled  in  some  manner  (usually  directly  by  the 
kernel).  Depending  upon  the  level  of  access 
mediation  incorporated  within  the  individual  serv¬ 
ers,  this  communication  mechanism  must  also 
unambiguously  provide  the  servers  with  identity 
and  privilege  information  of  all  clients  requesting 
services.  As  will  be  seen  below,  both  Aspen  ana 
Mach  provide  sophisticated  message-passing  mech¬ 
anisms  to  facilitate  this  type  of  inter-domain  com¬ 
munication. 


3.  ACCESS  MEDIATION 

As  a  result  of  our  efforts  to  develop  trusted  ver¬ 
sions  of  several  different  systems,  we  have  noted  a  small 


number  of  access  mediation  approache'.  for  server-ori¬ 
ented  systems.  All  of  these  approaches  are  based  upon 
the  locality  of  access  control  mechanisms  within  the 
system’s  architecture.  In  the  first  approach,  access  medi¬ 
ation  is  performed  within  the  kernel.  This  kernelized 
approach,  which  is  most  like  the  classic  "security  kernel" 

(6] ,  treats  both  clients  and  servers  as  subjects  external  to 
the  reference  validation  mechanism.  As  such,  the  servers 
can  augment  and  extend  the  kernel’s  access  control 
mechanisms  with  a  finer  granularity  of  access  mediation 
and  the  addition  of  supporting  policies  (e.g.,  audit),  but 
the  fundamental  access  control  enforcement  is  provided 
by  the  kernel.  A  kernelized  approach  to  access  media¬ 
tion  is  not  particular  to  server-oriented  systems  and  has 
been  the  common  approach  for  implementing  a  reference 
validation  mechanism  in  the  past.  For  example,  SCOMP 

[7] ,  KVM  [8],  and  KSOS  [9J  all  have  a  kernelized  refer¬ 
ence  validation  mechanism. 

In  contrast  to  a  kernelized  approach,  the  inherent 
structure  of  server-oriented  systems  suggests  the  pos¬ 
sibility  of  a  distributed  approach  to  access  mediation, 
Given  that  servers  constitute  independent  object-type 
managers,  it  follows  that  individual  servers  can  be  re¬ 
sponsible  for  mediating  access  to  the  objects  they  man¬ 
age.  This  approach  is  consistent  with  the  object-oriented 
concept  of  object-type  managers  that  are  responsible  for 
all  actions  related  to  their  objects.  Unlike  the  kernel, 
which  for  the  most  part  is  only  aware  of  the  primitive 
resources  it  offers,  a  server  is  aware  of  the  unique  nature 
of  its  more  abstract  objects  and  can  provide  a  tailored 
access  control  policy  for  that  object-type.  This  observa¬ 
tion  is  especially  true  for  discretionary  access  control 
policies  where,  for  example,  the  access  control  policy  for 
files  may  differ  greatly  from  that  for  mailboxes  though 
both  are  essentially  derived  from  the  same  primitive 
resource  (e.g.,  disk  storage). 

The  distributed  approach  results  in  an  reference 
validation  mechanism  that  is  distributed  among  the  vari¬ 
ous  servers  and  not  centralized  as  with  the  traditional 
security  kernel  approach.  However,  we  have  found  that 
such  an  approach  can  be  used  to  design  a  reference 
validation  mechanism  that  still  meets  the  criteria  of  a 
reference  monitor,  namely  tamperproof,  always  invoked, 
and  analyzable. 

There  are  two  variants  to  the  server-oriented  ap¬ 
proach  for  access  mediation  that  strike  a  compromise  be¬ 
tween  kernelized  and  completely  distributed  access  med¬ 
iation.  These  approaches  provide  server-based  access 
mediation,  but  in  a  centralized  fashion.  The  first  of 
these  approaches  involves  the  notion  of  a  front-end  or 
name  server ,  This  approach  assumes  that  all  client 
accesses  to  server-based  objects  is  via  a  common,  global 
naming  sphere,  managed  by  a  name  server.  The  name 
server  logically  resides  between  the  clients  tnd  the  other 
servers,  or  at  the  "front-end"  of  the  servers.  Requests  to 
access  objects  by  name  are  routed  directly  through  the 
name  server,  which  performs  access  validation  and.  if  the 
request  is  allowed,  passes  the  request  onto  to  the  ap¬ 
propriate  object-type  server.  Thus,  to  establish  com¬ 
munication  with  a  server  and  access  the  objects  that  that 
server  manages,  clients  must  first  pass  the  scrutiny  of  the 
name  server.  The  name  server  approach  provider  cen¬ 
tralized  access  mediation  while  exploiting  the  nature  of 
servers.  The  name  server,  which  operates  at  a  higher 
level  of  abstraction  than  the  kernel,  can  address  many  of 
the  idiosyncracies  associated  with  the  abstract  objects 
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offered  by  other  servers.  Conversely,  the  name  server 
may  require  considerable  richness  to  address  the  media¬ 
tion  concerns  of  all  object-types.  Hence,  information 
that  would  otherwise  be  maintained  solely  by  (he  object- 
type  server  must  be  available  to  the  name  server. 

The  second  centralized  server-based  approach  in¬ 
volves  the  notion  of  a  back-eihl  or  catalog  server . 
Unlike  a  name  server,  a  catalog  server  logically  resides 
between  the  servers  and  the  kernel,  or  at  the  "back-end" 
of  the  servers,  litis  approach  assumes  that  in  order  for 
individual  servers  to  access  the  kernel  resources  that  they 
manage,  they  must  reference  a  "card  catalog"  managed 
by  a  catalog  server.  Thus,  the  catalog  server  intercepts 
all  access  attempts  and,  if  properly  designed,  can  per¬ 
form  access  mediation  based  upon  a  combined  ser¬ 
ver/client  identity.  A  back-end.  catalog  server  approach 
to  access  mediation  has  many  of  the  same  pros  and  cons 
as  a  name  server  approach. 

In  the  systems  that  we  have  examined,  the  above 
approaches  were  all  considered.  Most  often,  the  idiosyn- 
cracies  of  the  particular  system  strongly  suggested  the 
selection  or  rejection  of  a  specific  approach.  In  Aspen 
for  example,  the  kernel  ized  approach  was  rejected  be¬ 
cause  it  would  have  placed  access  mediation  at  too  low 
a  level  to  be  meaningful  with  respect  to  server  objects. 
Performance  issues  were  also  of  concern.  By  contrast, 
in  Mach,  placing  some  mediation  in  the  kernel  appears 
to  be  the  approach  of  choice.  In  most  cases  the  realities 
of  the  system  architecture  suggests  a  combination  of 
approaches.  For  exumple.  in  Mach,  a  combination  of 
mediation  in  the  kernel  and  in  a  name  server  is  currently 
being  targeted.  In  the  following  sections,  the  approaches 
devised  for  both  Aspen  and  Mach  are  discussed  in  more 
detail. 


4.  ASPEN 

Amdahl  developed  Aspen  to  provide  a  lower  com¬ 
plexity,  higher  reliability  alternative  to  existing  .370 
operating  systems  that  would  be  compatible  with  most 
existing  application  software.  Though  Aspen  was  never 
marketed  many  of  its  design  concepts  were  innovative, 
especially  for  large,  mainframe  operating  systems. 


4.1  ASPEN  ARCHITECTURE 

Using  the  370  architecture’s  features  of  execution 
states  (supervisor  and  problem),  protection  keys,  fetch- 
protect  bit,  and  virtual  addressing  [10|,  Aspen  is  orga¬ 
nized  around  three  hierarchical  privilege  levels.  The 
most  privileged  level  is  the  Monitor ,  which  is  Aspen's 
equivalent  to  the  kernel  in  the  server-oriented  paradigm. 
The  Monitor  executes  in  supervisor-stute  in  u  portion  of 
real  memory  below  that  allocable  for  virtual  memory  and 
is  responsible  for  all  low-level  machine  management 
functions.  The  remaining  two  layers,  Supervisor  and 
Native ,  both  execute  in  the  problem-state  in  virtual  ad¬ 
dressing  mode.  Virtual  address  spaces  in  Aspen  are 
inulii-threaded,  that  is,  a  virtual  address  space,  called  a 
session ,  may  contuin  one  or  more  threads  of  execution, 
called  processes.  Each  session  is  a  distinct  address 
space  with  the  exception  of  a  portion  of  high  memory 
which  is  common  to  all  sessions  and  contains  the  Super¬ 
visor  layer.  Hence  the  Supervisor  layer,  though  ntnning 


in  virtual  addressing  mode,  is  present  in  all  sessions 
simultaneously.  Supervisor  code  and  data  stmetures  are 
protected  from  modification  and  observation  by  Native 
layer  code  via  the  370  architecture’s  storage  protection 
keys.  Supervisor  layer  memory  and  processes  have  a 
key=0  and  native  layer  memory  and  processes  have  a 
key>0.  Processes  with  key=0  may  access  any  page 
addressable  while  processes  with  key>0  may  only  access 
those  pages  with  the  same  key.  Thus,  the  Supervisor 
layer  is  able  to  coexist  within  the  same  virtual  address 
space  as  Native  layer  processes  without  interference  from 
them. 

The  Aspen  Supervisor  layer  is  organized  primarily 
as  a  collection  of  interacting  servers  that  together  pro¬ 
vide  most  of  the  traditional  operating  system  functional¬ 
ity  (e.g.,  files,  devices).  Additional  system  services  are 
provided  by  Native  layer  services  and  routines. 

4.1.1  Aspen  Concept  of  Servers 

Servers  are  u  well-defined  and  fundamental  con¬ 
cept  in  Aspen.  The  Transport  Manager,  which  runs  in 
the  Supervisor  layer,  provides  the  features  and  mech¬ 
anisms  that  allow  servers  and  clients  to  interact.  Servers 
are  essentially  processes  that  make  a  collection  of  ab¬ 
stract  "object-identifiers"  available  to  clients  via  an  offer. 
Servers  may  be  executing  in  either  the  Supervisor  or  the 
Native  layer.  All  servers  are  accessed  via  a  single  glob¬ 
al  naming  space  of  object-identifiers  managed  by  the 
Transport  Manager.  An  object-identifier  consists  of  five 
8-character  qualifiers,  which  are  referred  to  as  store, 
owner,  group,  type,  and  name.  A  fully  qualified 
object-identifier  is  of  the  form: 

store . owner . group . type . name  . 

An  offer  is  an  object-identifier  which  is  usually 
only  partially  qualified.  For  example,  an  offer  can  be  of 
the  form: 

A .B . * . * . *  . 


Such  an  offer  means  that  the  server  is  offering  to  handle 
requests  for  all  object-identifiers  where  the  first  two 
qualifiers  are  A  and  B.  An  offer  also  has  associated 
with  it  an  "extent",  which  determines  its  scope  of  visibil¬ 
ity.  Extents  may  either  be  local  or  global.  A  local-ex- 
tent  offer  is  only  visible  to  processes  within  the  same 
session  as  the  offering  server.  Conversely,  a  global- 
extent  offer  is  visible  to  processes  in  all  sessions. 

A  client  process  communicates  with  a  server  by 
issuing  a  request*  with  an  associated  fully  qualified 
object-identifier,  The  Transport  Manager  supports  two 
types  of  client  requests:  independent  and  related.  In¬ 
dependent  requests  establish  a  one-time  communication 
path  between  a  client  and  a  server  for  the  issuance  of  a 
single  request  and  the  reception  of  the  results  of  that 
request.  Such  requests  are  unrelated  to  any  other  re¬ 
quests  sent  to  the  server.  Typically .  independent  re¬ 
quests  include  DELETE,  DEFINE,  and  RENAME  opera¬ 
tions  on  an  object.  The  one-time  communication  path 
establ  died  for  an  independent  request  never  outlives  the 

*A  request  is  actually  a  software  generated  Interrupt  (MC  or  SVC 
instruction)  mat  is  trapped  by  the  Monitor  and  forwarded  to  the  Trunsport 
Manager  in  the  Supervisor  layer. 
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life  of  the  request.  The  exception  is  the  CONNECT 
independent  request,  which  establishes  a  connection  to  a 
server.  A  connection  is  a  long-term  communication  path 
to  a  server  that  exists  until  explicitly  destroyed  (either  by 
the  client  or  the  server).  Connections  are  used  for  re¬ 
lated  requests  and  allow  multiple  requests  to  be  associ¬ 
ated  in  an  ordered  fashion.  For  example,  a  connection 
to  a  file  object  can  be  used  to  do  multiple  READ  re¬ 
quests  such  that  each  successive  request  reads  the  next 
record  (relative  to  the  record  read  in  the  previous  re¬ 
quest).  The  Transport  Manager  manages  all  current 
connections  between  clients  and  servers. 

When  the  Transport  Manager  receives  an  indepen¬ 
dent  request  with  an  associated  object-identifier,  it  deter¬ 
mines  which  (if  any)  server  has  an  offer  that  matches 
that  object-identifier.  If  several  offers  match,  the  Trans¬ 
port  Manager  uses  the  following  precedence  rules  to 
select  the.  appropriate  server: 

(a)  The  most  fully  qualified  local  offer  first;  then 

(b)  The  most  fully  qualified  global  offer. 

Thus  for  example,  a  local  offer  A .  B  .*'.*.  *  would  tuke 
precedence  over  a  global  offer  A .  B .  C .  * .  *  even 
though  the  global  offer  is  more  fully  qualified. 

When  the  Transport  Manager  determines  the  ap¬ 
propriate  server,  it  forwards  the  request  to  that  server  for 
processing.  Based  upon  its  own  internal  logic,  the  server 
may  (1)  reject  the  request,  (2)  fail  the  request,  or  (3) 
accept  the  request.  If  a  server  rejects  a  request  (1),  the 
Transport  Manager  forwards  the  request  to  the  next 
server  which  has  a  matching  offer.  If  no  other  server 
has  a  matching  offer,  the  Transport  Manager  fails  the 
request  as  "object  not  found."  If  u  server  fails  the  re¬ 
quest  (2),  then  the  Transport  Manager  passes  the  failure 
back  to  the  client.  Finally,  if  the  server  accepts  the 
request  (3),  the  Transport  Manager  returns  the  results  of 
the  request  to  the  client.  If  a  server  accepts  a 
CONNECT  request,  then  the  Transport  Manager  estab¬ 
lishes  and  manages  a  connection  between  the  client  and 
the  server. 


4.1.2  Supervisor  Object-Type  Servers 

Object-identifiers  offered  by  a  server  have  no 
intrinsic  meaning,  nor  do  they  necessarily  represent  some 
actual  resource  or  resource  abstraction.  Actual  mapping 
of  system  resources  to  an  object-identifier  is  accom¬ 
plished  via  servers  and  their  internal  logic.  The  Super¬ 
visor  layer  consists  primarily  of  privileged  object-type 
servers.  The  major  servers  include  File  Server,  Sched¬ 
uler,  Terminal  Server,  Volume  Server,  and  Device  Serv¬ 
er.  Most  of  the  Supervisor  layer  servers  are  designed 
around  the  conventions  implemented  by  the  File  Server, 
which  is  discussed  in  detail  below. 

The  File  Server  manages  disk  storage  as  files, 
which  are  organized  into  stores  and  catalogs.  A  File 
Server  store  is  roughly  equivalent  to  a  logical  disk  vol¬ 
ume.  The  first  qualifier  of  a  file  object-identifier  deter¬ 
mines  the  store  on  which  the  file  is  maintained.  A  cata¬ 
log,  which  is  represented  by  the  second  qualifier  in  a  file 
object-identifier,  is  a  collection  of  files  all  with  the  same 
"owner."  The  owner’s  userlD  and  the  name  of  the  cata¬ 
log  in  which  the  owner’s  files  are  stored  are  syno¬ 


nymous,  All  files  in  a  catalog  are  owned  by  the  userlD 
that  is  reflected  by  the  catalog  name. 

The  File  Server  is  actually  a  collection  of  servers 
and  associated  offers,  each  server  executing  the  same 
Supervisor  layer  reentrant  code  within  different  contexts 
[11].  There  is  potentially  one  of  these  servers  for  every 
store  and  catalog  combination  on  the  system.  Each  of 
these  servers,  which  make  the  offer: 

"store_name"  .  "catalog_name"  ,*.*,*  , 

are  dynamically  activated  and  deactivated  as  references 
to  files  in  a  catalog  are  made.  Since  all  file  servers  ex¬ 
ecute  the  same  reentrant  code,  it  is  convenient  to  con¬ 
sider  them  as  a  single  File  Server  with  multiple  offers. 
The  remaining  three  qualifiers  of  a  file  object-identifier 
(group,  type,  and  name)  have  no  particular  meaning  to 
the  File  Server  other  than  to  uniquely  identify  a  file  and 
may  be  arbitrarily  specified  by  the  client.  All  files  are 
grouped  by  the  File  Server  based  solely  upon  their  store 
and  catalog  qualifiers. 

The  remaining  Supervisor  servers  offer  other 
system  resources  in  a  similar  fashion.  The  Device  Serv¬ 
er  directly  provides  all  primitive  functions  for  physical 
devices  (e.g.,  disks,  tape  drives,  printers,  terminals).  The 
Volume  Server  presents  tape  volumes  as  logical  exten¬ 
sions  of  the  file  system  using  the  Device  Server  to  ac¬ 
cess  the  tape  drives.  The  Terminal  Server  accesses 
terminal  devices  (via  the  Device  Server)  and  re-offers 
them  with  value-added  functionality.  The  Scheduler 
Server  accesses  terminal  devices  (via  the  Terminal  Serv¬ 
er)  to  initiate  the  logon  process  on  all  interactive  term¬ 
inals. 


4.1,3  Catalog  Manager 

Supervisor  servers  must  be  able  to  maintuin  des¬ 
criptive  information  about  their  objects  across  system 
initialization.  To  facilitate  this  ability,  Supervisor  servers 
use  object  information  blocks  (OIB),  which  are  objects 
offered  by  the  Catalog  Manager.  Typical  information 
stored  in  OlBs  include  locution,  name,  type,  size,  owner, 
and  creation,  modification,  and  reference  dates  for  ob¬ 
jects.  Though  the  Catalog  Manager  is  a  server,  it  only 
services  Supervisor  Layer  clients.  Native  layer  clients 
access  the  catalog  information  associated  with  an  object 
through  the  server  (hat  manages  that  object-type.  For 
example,  a  file's  OIBs  are  made  available  to  client  ses¬ 
sions  via  the  File  Server  as  purt  of  the  its  offered  ab¬ 
stractions. 

As  its  name  implies,  the  Catalog  Manager  man¬ 
ages  OIBs  in  groups  called  "catalogs."  For  example,  a 
File  Server  catalog  described  above  has  a  one-to-one 
correspondence  to  a  Catalog  Manager  catalog.  The  File 
Server  maintains  the  necessary  information  to  describe 
ail  the  files  in  a  file  system  catalog  in  one  Catalog  Man¬ 
ager  catulog.  Thus,  when  a  client  makes  a  request  to  the 
File  Server  to  access  a  file,  the  File  Server  makes  a 
request  to  the  Catalog  Manager  to  access  the  catalog  of 
file  OIBs  in  order  to  determine  the  existence  of  the  file 
and  locate  the  file  on  the  appropriate  store.  A  similar 
interaction  occurs  between  the  other  Supervisor  servers 
and  the  Catalog  Manager. 

The  Catalog  Manager  has  a  special  relationship 
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with  the  File  Server  that  is  different  than  its  relationship 
with  the  other  Supervisor  servers.  OIBs  must  be  stored 
in  some  fashion.  Since  the  File  Server  manages  all  disk 
stores,  it  is  necessary  for  the  Catalog  Manager  to  use  the 
File  Server’s  services  to  store  and  maintain  its  catalogs. 
This  results  in  a  recursive  relationship  between  the  Cata¬ 
log  Manager  and  the  File  Server.  Thus,  the  Catalog 
Manager  and  File  Server  are  required  to  cooperate  in  an 
environment  of  mutual  dependency. 


4. 1 .4  Native  Layer  Servers 

Aspen’s  server  concept  is  fully  exported  to  the 
Native  layer.  Thus,  Native  layer  servers  can  be  created 
that  act  and  behave  exactly  the  same  as  Supervisor  layer 
servers.  However,  because  Native  layer  servers  are  sig¬ 
nificantly  less  privileged  than  their  Supervisor  layer 
counterpart,  the  Transport  Manager  levies  additional 
constraints  on  the  offers  that  these  servers  may  make  as 
discussed  below. 

Offers  may  become  overloaded  with  several  offers 
matching  the  same  fully  qualified  object-identifier.  For 
example,  the  File  Server  may  offer  object-identifiers 
A.B.*.*.*  while  a  Native  level  server  may  offer  ob¬ 
ject-identifiers  A .  B .  C .  * .  * .  In  (his  case,  if  the  Native 
layer  server’s  offer  is  global,  it  would  intercept  all  re¬ 
quests  to  access  file  names  with  A.B.C  as  their  first 
three  qualifiers.  In  general,  the  Transport  Manager  only 
allows  Native  layer  servers  to  make  global  offers  that 
overload  Supervisor  layer  servers  if  the  owner  (second) 
qualifier  in  the  offer  is  the  same  as  the  Native  layer 
server’s  userlD.  Thus.  Native  layer  servers  may  only 
intercept  requests  to  objects  for  which  they  are  the  own¬ 
er.  essentially  a  form  of  discretionary  access  control, 
Generally,  there  are  no  restrictions  on  any  local  offers  or 
those  global  offers  that  do  not  overload  a  Supervisor 
server. 


4.2  ACCESS  CONTROL  IN  ASPEN 

Aspen  incorporates  many  of  the  server-oriented 
characteristics  discussed  curlier.  Separate  server  and 
client  domains  exist  through  the  provision  of  distinct 
address  spaces  (sessions).  Aspen  further  extends  the 
concept  of  domains  by  providing  the  Supervisor  and 
Native  layers,  allowing  for  servers  and  clients  at  dif¬ 
ferent  hardware  privilege  levels.  Inter-domain  communi¬ 
cation  is  facilitated  viu  the  Transport  Manager-provided 
concepts  of  offers,  requests,  and  connections,  While  the 
Transport  Manager  does  not  maintain  descriptive  infor¬ 
mation  about  object-identifiers,  it  does  arbitrate  all  traffic 
between  clients  and  servers,  making  it  very  similar  to  a 
front-end  name  server. 

Aspen  was  originally  designed  with  a  strong  con¬ 
cept  of  ownership  and  related  discretionary  access  con¬ 
trol  mechanisms  as  its  primary  means  of  access  control, 
Incorporating  mandatory  access  controls  was  a  major 
issue  in  developing  the  design  for  trusted  Aspen. 
Aspen’s  architecture  requires  that  processes  in  the  Super¬ 
visor  layer  be  trusted,  hence  Aspen’s  TCB  roughly  in¬ 
cludes  all  of  the  Kernel  and  Supervisor  layers,  plus 
selected  processes  running  in  the  Nutive  layer  (12|, 
Sessions  in  Aspen  are  the  basic  unit  of  resource  allo¬ 


cation  and  as  such,  a  session  with  its  associated  Native 
layer  processes  are  treated  as  a  single  subject.  All  ses¬ 
sions  have  an  associated  userlD  and  (for  the  trusted 
design)  a  security  level.  The  major  objects  of  the  sys¬ 
tem  are  the  abstractions  offered  by  Supervisor  layer  ser¬ 
vers  (e.g„  files,  tape  volumes,  devices,  scheduling 
queues). 


4.2.1  Ownership  and  Discretionary  Access  Control 

Aspen  was  originally  designed  such  that  Super¬ 
visor  servers  determined  whether  a  request  to  access 
their  objects  should  be  honored.  The  T  ransport  Man¬ 
ager,  which  controls  all  client-server  communication, 
determines  which  server  should  receive  a  request,  but  the 
individual  server  determines  whether  the  request  is  ac¬ 
cepted.  As  before,  most  Supervisor  servers  imitate  the 
conventions  used  by  the  File  Server,  which  includes  a 
rigid  concept  of  ownership  in  which  the  file’s  owner 
implicitly  has  all  access  to  the  file.  A  file  owner,  re¬ 
flected  by  the  second  identifier  in  the  file’s  object-ident¬ 
ifier,  may  either  be  a  user  or  an  account.  Accounts  are 
groups  of  users  and  members  of  an  account  have  implicit 
access  to  files  owned  by  that  account. 

Associated  with  each  file  is  an  access  control  list 
(ACL)  that  provides  the  ability  for  the  file  owner  to 
specify  lists  of  individuals  (userlDs)  and  group  of  in¬ 
dividuals  (accountIDs)  with  specific  access  modes  (e.g., 
read,  write,  delete,  execute).  ACLs  are  kept  as  file  OIBs 
managed  by  the  Catalog  Manager.  Servers  enforce  dis¬ 
cretionary  access  control  decisions  in  two  manners.  In¬ 
dependent  requests  are  interpreted  separately  and 
accepted  or  denied  based  on  the  client’s  userlD.  Related 
requests,  however,  are  mediated  in  an  entirely  different 
manner.  When  a  connection  is  established,  it  is  created 
with  an  associated  access  mode,  which  is  either  read  or 
write.  When  a  client  issues  a  CONNECT  request,  it 
includes  the  desired  access  mode.  The  File  Server  vali¬ 
dates  whether  the  client  has  access  to  the  file  in  the  re¬ 
quested  mode  and  if  so.  accepts  the  request.  Once  the 
connection  is  accepted,  the  Transport  Munager  maintains 
the  connection’s  access  inode  and  makes  it  available  to 
the  connected  server.  Thus,  once  the  File  Server  allows 
a  connection  in  a  particular  mode,  it  need  only  ensure 
that  all  subsequent  related  requests  associated  with  that 
connection  are  appropriate  for  the  connection's  access 
mode. 

From  the  above  description,  it  would  appear  that 
Aspen  incorporates  u  distributed  approach  to  discretion¬ 
ary  access  mediation.  However,  the  details  of  how 
Supervisor  servers  implement  this  mediation  is  more  like 
a  back-end  catalog  server  approach.  As  previously 
described,  the  File  Server  interacts  with  the  Catalog 
Manager  to  access  catalogs  of  file  OIBs.  This 
interaction  is  actually  via  a  connection  between  the  File 
Server  and  the  Catalog  Server  to  the  appropriate  catalog. 
It  is  via  this  connection  that  the  File  Server  accesses  the 
file  OIBs  associated  with  a  particular  catalog  and  deter¬ 
mines  whether  the  file  exists.  For  example,  if  a  client 
requests  access  to  a  file  A.B.C.D.E,  the  File  Server 
first  establishes  a  connection  (if  not  already  established) 
to  the  catalog  A.B  managed  by  the  Catalog  Manager. 
The  File  Server  then  requests  (via  this  connection)  the 
OIBs  for  file  C.D.E.  If  the  file  does  not  exist,  the 
Catalog  Manager  informs  the  File  Server  which  informs 
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the  client.  For  independent  requests,  the  File  Server  in¬ 
cludes  the  client's  userlD  in  the  request  to  access  the 
file’s  OIBs.  Using  this  information,  the  Catalog  Manager 
makes  the  decision  whether  the  client  can  access  the  file. 
The  File  Server  only  enforces  the  Catalog  Manager’s 
decision  by  assuring  that  related  requests  received  across 
an  established  connection  are  appropriate  for  the  access 
mode  associated  with  the  connection. 

The  major  exception  to  this  approach  for  dis¬ 
cretionary  access  mediation  is  the  Scheduler  server, 
which  does  not  use  OIBs  to  maintain  information  about 
its  scheduling  queues  called  transaction  tables.  Rather, 
the  Scheduler  stores  this  information  directly  in  private 
files  (of  course,  via  the  File  Server).  Thus,  the  Sched¬ 
uler  enforces  discretionary  access  control  on  transaction 
tables**  directly,  without  direct  interaction  of  the  Catalog 
Manager. 


4.2.2  Mandatory  Access  Control 

Since  Aspen  relies  heavily  on  servers  for  provid¬ 
ing  access  to  system  resources,  the  major  task  for  in¬ 
corporating  mandatory  access  control  into  Aspen  was  to 
control  client-server  interaction.  In  this  effort,  all  four  of 
the  server-oriented  access  mediation  approaches  (kentel- 
ized,  front-end,  back-end,  and  distributed)  were  ex¬ 
amined.  A  kemelized  approach  was  ruled  out  quite 
early.  The  main  reason  for  this  decision  is  that  the 
Aspen  Monitor  was  nearly  completed  and  Amdahl  pre¬ 
ferred  not  to  significantly  modify  it.  F.ven  so,  Aspen 
was  designed  such  that  access  mediation  for  server-based 
objects  was  not  meaningful  in  the  kernel.  The  architec¬ 
ture  of  Aspen  strongly  suggested  a  server-based  approach 
for  access  mediation. 

The  initial  approach  attempted  to  have  server- 
related  access  mediation  performed  in  a  central  location 
by  the  Transport  Manager  (i.e..  Iront-end  mediation).  It 
was  appurent  that  the  Transport  Manager  had  to  perform 
some  access  mediation.  Since  servers  and  clients  can 
both  be  untrusted  Native  layer  subjects,  the  Transport 
Manager’s  server-client  abstractions  provide  a  major 
mechanism  for  inter-subject  communication.  Additional¬ 
ly,  offers  mude  by  a  server  may  contain  up  to  40  char¬ 
acters  of  information  which,  if  global,  would  be  visible 
to  all  sessions.  Thus,  the  Transport  Manager  hud  to  be 
modified  to  associate  security  levels  with  all  offers  made 
by  Native  layer  servers  that  could  be  used  to  restrict 
communication  with  such  servers.  A  global  offer  made 
by  a  Native  server  would  only  be  visible  to  Native  layer 
sessions  at  the  same  security  level.  Thus,  since  a  client 
muy  only  send  requests  to  offers  that  are  visible  to  it, 
untrusted  server-client  communication  is  controlled  by 
the  Transport  Manager. 

However,  extending  this  notion  to  Supervisor  layer 
servers  proved  more  difficult.  The  nature  of  the  Super¬ 
visor  servers  demonstrated  that  they  each  must  be  fully 
trusted  servers,  servicing  requests  from  clients  at  all 
security  levels  in  addition  to  other  trusted  Supervisor 
layer  servers.  Further,  the  problem  with  Supervisor  layer 
servers  is  not  necessarily  controlling  access  to  the  serv¬ 
ers,  but  rather  controlling  access  to  the  resources  the 
servers  manage.  Thus,  mandatory  uccess  control  for 
Supervisor  servers  has  to  be  based  upon  the  resources 
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represei  ted  by  an  object-identifier  associated  with  a 
request  and  not  the  offer  made  by  the  server. 

In  order  for  the  Transport  Manager  to  perforin 
mediation  based  on  individual  object-identifiers,  it  must 
possess  the  appropriate  information  (e.g.,  security  level) 
about  the  object.  Further,  this  information  differs  de¬ 
pending  on  the  object-type  (e.g.,  multilevel  devices 
versus  single-level  devices).  In  addition,  the  nature  of  a 
request  is  also  dependent  upon  the  object-type  and  re¬ 
quires  an  understanding  of  how  the  managing  server 
implements  the  request.  Thus,  to  facilitate  the  Transport 
Manager’s  ability  to  perform  access  mediation  for  Super¬ 
visor  servers’  objects,  it  must  maintuin  (or  access)  this 
information  about  the  objects.  Unfortunately,  the  Tran¬ 
sport  Manager  was  not  originally  designed  as  a  true 
name  server,  rather  it  was  designed  to  simply  resolve 
overloaded  offers  and  to  facilitate  client-server  communi¬ 
cation.  Its  design  did  not  encourage  the  addition  of  this 
added  information,  which  would  essentially  be  redundant 
with  the  logic  already  provided  by  the  individual  server. 
An  alternative  was  to  have  the  individual  servers  per¬ 
form  mediation  themselves. 

The  final  design  proposed  for  Aspen  incorporated 
mandatory  access  controls  for  Supervisor  server  objects 
in  a  fashion  as  was  originally  designed  for  discretionary 
access  controls,  i.e.,  via  individual  servers  interaction 
with  the  Catalog  Manager.  In  addition  to  passing  the 
client’s  userlD  when  requesting  a  file’s  OIBs,  the  Super¬ 
visor  servers  would  also  pass  the  client’s  security  level 
allowing  the  Catalog  Munuger  to  determine  whether  the 
client  may  access  the  file  in  the  requested  mode.  For 
related  requests,  once  the  Catalog  Manager  validated  the 
creation  of  a  connection,  the  individual  server  would 
need  only  ensure  that  the  connection  is  used  to  access 
only  the  associated  object  in  the  associated  mode. 


4.3  ASPEN  SUMMARY 

Though  the  upgrade  for  Aspen  was  only  partially 
implemented  at  the  time  the  effort  was  discontinued,  a 
multilevel  secure  design  for  Aspen  had  been  nearly  com¬ 
pleted.  Discretionary  access  controls  were  included  in 
Aspen’s  original  design  and  were  implemented  as  a  co¬ 
operative  effort  between  the  individual  Supervisor  servers 
and  the  back-end  Catalog  Manager.  The  multilevel 
design  of  Aspen  split  mandatory  access  controls  between 
the  cooperative  relation  of  the  individual  servers  and  the 
Catalog  Munuger  for  trusted  server-bused  objects,  and  the 
front-end  Transport  Manager  for  untrusted  server-client 
interactions.  Though  this  approach  to  mandatory  access 
control  resulted  in  u  distributed  reference  validation 
mechanism,  its  highly-structured  architecture  appeared  to 
ullowed  the  mediation  mechanisms  to  be  u  faithful  im¬ 
plementation  of  the  reference  monitor  concept. 


5.0  MACH 

Mach  is  currently  an  operating  system  kernel  that 
is  designed  to  be  transportable  over  a  range  of  differing 
hardware  from  microprocessors  to  large  parallel 
machines.  Because  of  this  design  goal,  dependence  upon 
specific  hardware  features  is  minimal.  Although  most  of 
the  features  of  the  Mach  kernel,  as  specified  in  the  Mach 
Kernel  Interface  Manual  [13],  have  been  implemented, 


the  nonkemel  servers  that  will  provide  the  bulk  of  the 
system  functionality  are  currently  being  designed  by 
CMU.  It  is  expected  that  the  CMU  design  will  follow 
the  general  pattern  of  Accent,  the  precursor  of  Mach. 
Mach  is  still  a  prototype  system  in  a  state  of  rapid  evo¬ 
lution.  Under  DARPA  contract,  TIS  is  developing  a 
Trusted  Mach  (TMach)  prototype  that  will  provide  a 
proof-of-concept  for  the  transformation  of  a  fully  kem- 
elized,  server-oriented  Mach  system  into  a  trusted  operat¬ 
ing  system. 


5.1  TMACH  ARCHITECTURE 

TMach  is  structured  as  a  kernel  which  provides  a 
small  set  of  basic  objects  and  services,  and  a  collection 
of  system  servers  that  provide  the  bulk  of  the  operating 
system  functionality.  Since  Mach  is  designed  to  be 
transportable,  little  is  specified  about  the  mapping  to  any 
one  hardware  configuration;  however  some  assumptions 
are  made  about  the  hardware  base.  It  is  tacitly  expected 
that  any  hardware  will  huve  at  least  two  execution  states, 
The  Mach  kernel  executes  in  the  most  privileged  state 
and  the  system  servers  (along  with  untrusted  user  ap¬ 
plications)  execute  in  the  unprivileged  state.  Address 
space  separation  provides  system  servers  protection  from 
each  other  and  other  system  entities.  Additional  hard¬ 
ware  protection  features  are  used  if  they  exist,  but  are 
not  assumed  by  the  CMU  design. 

5.1.1  The  Kernel 

The  Mach  kernel  handles  process  management, 
interprocess  communication,  and  memory  management. 
In  the  fully  kemelized  system  it  will  also  handle  low 
level  I/O  and  device  management.  Currently  the  Mach 
kernel  supports  four  basic  abstractions.  A  task  is  an 
execution  environment  and  the  basic  unit  of  resource 
allocation.  Each  task  is  a  separate  virtual  address  space. 
A  thread  is  the  basic  unit  of  execution.  A  task  may 
have  several  threads  executing  within  its  environment,  all 
having  access  to  the  same  set  of  resources.  A  port,  the 
most  central  abstraction  in  Much,  is  a  message  queue 
protected  by  the  kernel  and  also  act  as  the  basic  object 
reference  mechanism.  In  addition,  ports  are  also  used  as 
the  primary  mechanism  for  tasks  to  communicate  with 
the  kernel.  A  message  is  a  typed  collection  of  data  used 
in  communication  via  ports.  A  message,  which  has  a 
fixed  size  header  and  a  variable  size  body,  can  include 
the  transfer  of  access  rights  to  ports. 

Ports  have  three  types  of  access  rights  associated 
with  them:  send,  receive,  and  own.  A  port  may  only 
have  a  single  receiver  and  single  owner  but  any  number 
of  tasks  may  possess  send  rights  to  the  same  port. 
Receive  and  own  rights  to  a  port  also  imply  send  rights 
to  that  port.  Threads  and  tasks  are  represented  by 
special  ports  called  tasks  ports  and  thread  ports,  The 
kernel  holds  both  receive  and  own  rights  to  all 
task_ports  and  thread_ports.  Any  task*"  that  holds  send 
rights  to  a  task_port  or  thread_port  can  issue  commands 
to  the  kernel  for  which  the  results  of  the  command  will 
affect  the  associated  task  or  thread, 


Although  >  luk  It  limply  on  execution  environment,  for  simplicity  of 
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Message  passing  is  the  primary  means  of  com¬ 
munication  both  among  tasks  and  between  tasks  and  the 
Mach  kernel  itself.  Thus  information  flows  in  the  sys¬ 
tem  is  the  result  (directly  or  indirectly)  of  the  kernel 
processing  message  send  or  receive  requests.  The  only 
commands  implemented  by  system  traps  are  those  direct¬ 
ly  concerned  with  message  communication  (msg_send, 
msg_receive,  and  msg_rpc)  and  a  few  others 
(task_self,  task_data,  task_notify,  and 
thread_self).  The  rest  are  implemented  by  sending 
messages  to  a  task_port  or  thread_port,  all  of  which  have 
the  kernel  as  the  receiver. 

5.1.2  System  Servers 

The  bulk  of  TMach  functionality  is  provided  by  a 
set  of  system  servers.  The  most  central  of  these  servers 
is  the  Name  Server  which  provides  (with  support  from 
the  kernel)  the  mechanisms  by  which  servers  and  clients 
can  interact.  The  Name  Server  essentially  manages  a 
hierarchical  directory  structure  of  server-managed  ab¬ 
stractions  called  items.  Tlte  Name  Server  maintains 
certain  descriptive  information  about  each  defined  item 
including  its  relationship  within  the  directory  tree,  its 
name,  and  its  item  type.  All  defined  items  are  an  instan¬ 
tiation  of  an  item  type  (e.g.,  directory,  file).  Each  item 
type  is  managed  by  a  particular  server  which  is  iden¬ 
tified  by  a  port,  called  a  server-port ,  to  which  the  Name 
Server  possesses  send  rights.  The  Name  Server  itself 
directly  manages  all  directory  item  types.  Client  tusks 
access  a  particular  item  by  sending  u  request  to  the 
Name  Server  which  in  turn  routes  the  request  to  the 
server-port  for  items  of  thut  type.  Other  system  servers 
that  will  be  included  in  our  prototype  include  File  Server 
(mass  storage  management).  Verification  Server  (user 
identification  and  authentication),  SysAdmin  Server 
(support  for  system  administration),  and  Audit  Server 
(collection  and  query  of  audit  data). 

Architecturally,  TMach ’s  trusted  servers  avoid  the 
mutual  dependency  problems  that  Aspen  possessed.  The 
Name  Server  is  logically  the  most  primitive  of  all  the 
trusted  servers.  Therefore,  the  Name  Server  will  only 
depend  upon  the  kernel  for  its  correct  operation.  The 
kernel  provides  direct  support  for  storage  and  retrieval  of 
the  Name  Server’s  internal  database  ensuring  that  the 
Name  Server  is  not  dependent  upon  the  File  Server.  The 
remaining  servers  may  depend  upon  the  Name  Server  for 
storage  of  private  information  (e.g.,  the  File  Server  may 
store  disk  addressing  information  with  each  file  item 
record  maintained  by  the  Name  Server).  Our  current 
plans  are  for  trusted  servers  other  than  the  Name  Server 
to  depend  upon  the  File  Server  for  mass  storage  require¬ 
ments. 


5.2  ACCESS  CONTROL  IN  TMACH 

In  the  current  TMach  design,  access  control  is 
provided  by  the  kernel  for  basic  system  objects  (i.e., 
ports,  tasks)  and  by  the  Name  Server,  in  conjunction 
with  the  kernel,  for  server-managed  objects. 

5.2.1  Access  Control  in  the  Kernel 

In  a  very  real  sense,  ports  are  similar  to  capabil¬ 
ities  [14],  The  kernel  maintains  the  equivalent  of  a 
capability-list  for  each  task  that  defines  which  ports  the 
task  can  name  and  in  which  inode  (e.g,,  send,  receive). 
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However,  Mach’s  implementation  of  polls  avoids  the  in¬ 
herent  access  control  inabilities  commonly  associated 
with  capability-based  systems  [15).  Specifically,  tasks 
can  not  pass  port-rights  directly  to  other  tasks.  The 
"capability-list"  for  each  task  is  implemented  as  a  global, 
kernel-protected  hash  table  called  the  T-P  tabic.  Port- 
rights  for  a  task  may  be  added  to  this  table  in  only  a 
few  well-defined  ways  —  primarily  via  the  message  send 
and  receive  kernel  primitives  (i.e.,  msg_send, 
msg_receive,  msg__rpc).  The  kernel  recognizes 
when  a  message  contains  a  transfer  of  a  port-right  and 
updates  the  T-P  table  accordingly. 

In  TMach.  the  kernel  will  mediate  all  transfers  of 
port-rights  to  ensure  that  no  task  possesses  a  right  in 
violation  of  the  system  security  policy.  This  is  accom¬ 
plished  by  mediating  all  messages  that  contain  a  transfer 
of  a  poll-right.  Once  a  task  obtains  a  port-right,  it  may 
use  the  port  without  further  mediation  by  the  kernel.  In 
this  manner,  access  to  pons  and  therefore  the  flow  of 
message  traffic  is  guaranteed  to  be  consistent  with  the 
system  security  policy.  li  is  expected  that  the  addition 
of  this  mediation  on  port-right  transfers  will  have  a  very 
small  impact  on  the  performance  of  the  Mach  kernel. 

The  kernel  performs  two  forms  of  access  media¬ 
tion.  The  first  is  a  mandatory  label-based  security  policy 
that  is  an  interpretation  of  the  Bell-LaPadula  model  [I6J. 
The  kernel  maintains  security  levels  for  all  tasks  and 
ports.  Tasks  have  two  levels,  maximum  and  minimum, 
that  define  a  range  over  which  a  task  may  possess  port- 
rights.  The  actual  security  policy  enforced  N  a  direct 
derivative  the  Bell-LuPadula  model’s  simple-security 
condition  and  ‘-property  [I7|.  The  majority  of  tasks 
(e.g..  all  untrusted  user  tasks)  will  have  their  maximum 
and  minimum  security  levels  set  exactly  the  same  (i.e., 
single-level  subjects), 

The  second  form  of  access  mediation  within  the 
kernel  is  an  identity-based  security  policy.  The  kernel 
maintains  u  user  ID  for  all  tasks  and  can  determine  which 
task  currently  holds  receive  rights  for  all  ports.  Using 
this  information,  the  kernel  enforces  the  following  addi¬ 
tional  constraints  on  the  transfer  of  port  rights: 

(1)  Receive  and  own  rights  for  a  port  P  cannot  be 
transferred  unless  both  the  sending  and  receiving 
tasks  have  the  same  userlD  ;  and 

(2)  Send  rights  for  a  port  P  cannot  be  transferred 
unless  both  the  sending  and  receiving  tasks  have 
the  same  userlD,  or  the  sending  task  and  the  task 
which  currently  possess  receive  rights  for  port  P 
have  the  same  userlD. 

The  first  constraint  essentially  disallows  the  transfer  of 
any  receive  right  except  among  tasks  of  the  same 
userlD.  The  second  constraint  allows  a  task  to  transfer 
send  rights  to  another  task  only  if  it,  or  another  task 
with  the  same  userlD,  has  control  of  the  port.  TMach 
also  provides  two  privileges  that  may  be  associated  with 
tasks.  Transfer-receive-rights  privilege  allows  a  task  to 
violate  constraint  (1)  and  transfer-send-rights  privilege 
allows  a  task  to  violate  constraint  (2).  These  identity- 
based  controls  are  not  discretionary  as  normally  associ¬ 
ated  with  identity-based  policies,  but  rather  are  man- 
datorily  enforced  by  the  kernel.  They,  along  with  the 
associated  privileges,  provide  the  "hooks"  that  can  be 


used  to  enforce  a  more  traditional  discretionary  access 
control  policy  on  server-based  objects  or  perhaps  a  more 
interesting  identity-based  policy. 

5.2.2  Access  Control  in  the  Servers 

For  TMach,  the  locus  of  access  mediation  for 
server-based  objects  will  be  within  the  Name  Server, 
which  will  be  a  multilevel  task  which  possesses  the 
transfer-send-rights  privilege.  The  Name  Server  will 
enforce  both  mandatory  and  discretionary  access  control 
policies  with  the  assistance  of  the  kernel  provided  con¬ 
trols  discussed  above.  Since  all  interaction  between 
clients  and  servers  must  be  initiated  via  the  Name  Serv¬ 
er,  it  provides  a  centrul  location  in  which  the  kernel’s 
security  policy  can  be  extended  to  more  abstract  objects. 
Fhe  controls  enforced  by  the  Name  Server  are  of  two 
forms,  those  placed  upon  the  server  tasks  and  those 
placed  upon  the  client  tasks. 

Servers  offer  items  by  registering  themselves  with 
the  Name  Server.  This  registration  consists  of  two 
phases.  The  first  is  to  create  an  item  type  by  defining 
an  type-record  to  the  Name  Server.  The  Name  Server 
maintains  these  records  along  with  the  userlD  and  secur¬ 
ity  levels  of  the  creating  task  and  a  specified  access 
control  list  (ACL).  The  second  phase,  which  can  occur 
concurrently  with  the  creation  of  a  type-record  or  sep¬ 
arately  (i.e.,  for  permanent  item  types  such  as  files),  is  to 
provide  the  Name  Server  with  a  port  over  which  the 
server  will  receive  requests  for  items  of  that  type.  In 
order  to  register  this  port,  called  a  server -port,  the  serv¬ 
er’s  task  must  have  the  same  userlD  of  the  type-record's 
creator  and  have  the  exact  same  maximum  and  minimum 
security  levels  as  stored  in  the  type-record. 

Client  tasks  access  all  server-managed  objects  via 
the  naming  conventions  implemented  in  the  directory 
tree  structure  maintained  by  the  Name  Server.  Client 
tusks  cannot  directly  access  (and  therefore  directly  name) 
items  maintained  by  servers.  All  references  to  server- 
managed  items,  including  their  creation  and  deletion,  is 
directly  managed  and  mediated  by  the  Name  Server. 
When  ar.  item  is  created,  the  Name  Server  ensures  that 
the  client  is  both  on  the  ACL  for  that  item  type  and  has 
maximum  and  minimum  security  levels  within  the  range 
stored  for  that  item  type  (this  prevents  illicit  communica¬ 
tion  between  clients  and  servers).  When  an  item  is 
created,  the  Nume  Server  associates  with  the  item  the 
security  level  of  the  creating  task  (or  for  multilevel 
creating  tusks,  a  specified  security  level  within  the  task’s 
maximum  and  minimum  security  levels)  and  an  ACL 
specified  by  the  client.  To  subsequently  access  an  item, 
a  client  lusk  sends  a  request  to  the  Name  Server  specify¬ 
ing  the  name  of  an  item  and  a  port  over  which  a  re¬ 
sponse  is  expected  (called  a  reply-port).  The  Name 
Server  will  mediate  the  request  and,  if  the  request  passes 
access  mediation,  will  forwurd  the  request  along  with  the 
reply -port  (hence  the  need  for  transfer-send-rights  priv¬ 
ilege)  to  the  server-port  for  items  of  that  type.  In  the 
case  of  single-level  servers,  this  mediation  (along  with 
the  kernel’s  controls  on  the  transfer  of  port-rights)  is 
sufficient  to  ensure  that  communication  is  in  accordance 
with  the  system  security  policy.  In  the  cuse  of  trusted 
multilevel  servers,  the  servers  arc  expected  to  function 
correctly  but  are  not  expected  to  enforce  any  additional 
constraints.  For  example,  the  File  Server,  after  receiving 
a  request  to  open  a  file  for  "read",  must  ensure  that  it 
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only  allows  the  client  to  "read"  the  file  since  the  Name 
Server  mediated  the  request  for  "read"  access.  One  man¬ 
ner  in  which  this  may  be  accomplished  is  for  the  File 
Server  to  create  a  port,  associate  the  port  with  the  target 
file,  transfer  send  rights  for  the  port  to  the  client  via  the 
client’s  reply-port,  and  ensure  that  subsequent  requests 
received  via  this  port  are  all  "read"  in  nature. 


5.3  MACH  SUMMARY 

The  current  TMach  effort  is  to  develop  a  proto¬ 
type  system  that  explores  the  feasibility  of  developing  a 
B3  system  bused  upon  CMU’s  Mach  kernel.  The  current 
Mach  kernel  is  not  complete  and  relies  upon  UNIX*”  to 
perform  all  I/O  functions.  However,  we  expect  that  a 
complete  kernel  (i.e„  the  inclusion  of  I/O  and  device 
control)  can  support  a  highly  trusted  system.  Tire  kernel 
will  eventually  provide  only  task/ihread  management, 
most  memory  management,  message-passing  capabilities, 
and  primitive  I/O  and  device  management.  We  expect 
that  a  general-purpose  server-based  system  built  upon 
this  kernel  can  meet  the  B3  requirements.  In  the  case  of 
the  TMach  prototype,  the  Name  Server  provides  a  locus 
for  additional  access  mediation  required  for  the  more 
abstract  server-managed  objects  while  the  kernel  provides 
resource  isolation,  controlled  message-passing,  and  ac¬ 
cess  mediation  for  primitive  objects,  litis  allows  a 
server  layer  to  be  constructed  that  exhibits  strong  modul¬ 
arity  and  independence  among  the  trusted  servers.  Our 
initial  proof-of-coneept  prototype  is  expected  to  bo  oper¬ 
ational  by  the  end  of  this  year. 


6.0  CONCLUSIONS 

We  have  found  that  server-based  mediation  can  be 
used  to  implement  a  reference  validation  mechanism  that 
is  entirely  faithful  to  the  Reference  Monitor  Concept, 
litis  conclusion  is  supported  by  the  fact  that  the  inherent 
structure  of  such  systems  allow  access  controls  to  be 
included  in  trusted  servers  such  that  the  completeness 
and  correctness  of  the  mediation  mechanisms  can  be 
assured.  The  trusted  designs  of  both  Aspen  and  Mitch 
incorporate  access  controls  within  servers.  Aspen's 
mediation  is  designed  entirely  in  the  Supervisor  layer 
while  TMach  has  a  kernel  which  provides  resource 
isolation  and  access  mediation  on  primitive  objects  and  a 
Name  Server  which  (in  conjunction  with  the  kernel) 
provides  access  mediation  for  more  abstract  objects. 

It  is  apparent  from  Aspen,  Mach,  and  other  sys¬ 
tems  we  have  examined,  that  the  server-oriented  para¬ 
digm  is  becoming  a  popular  design  philosophy  in  new 
operating  system  development  efforts.  We  feel  that  in 
many  cases,  reference  validation  contained  entirely  with¬ 
in  a  security  kernel  is  not  an  optimal  solution  to  access 
control  concerns  for  this  type  of  system.  A  server-based 
approach  for  access  mediation  is  a  viable  alternative. 
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ABSTRACT 

The  Logical  Coprocessing  Kernel  (LOCK)  is  a  Trusted  Computing  Base  (TCB)  that 
is  designed  to  meet  and  exceed  the  requirements  for  a  Class  A1  secure  system. 
This  paper  describes  the  results  of  a  study  that  determined  how  to  port  the 
Unix*  System  V  Operating  System  to  the  LOCK  TCB,  while  maintaining  maximum 
compatibility  with  the  System  V  Interface  Definition  (SVID)  [SVID86] . 


1 . 0  Background  of  the  Problem 

Over  the  years,  Unix  has.  gained  widespread 
acceptance  as  the  da-  facto  standard  Operating 
System  (OS)  within  the  U.S.  Government  and 
private  industry.  During  the  same  time  that 
Unix  has  gained  in  popularity,  a  demand  for 
secure  computing  systems  '  has  developed. 
Recently,  the  demands  for  these  two  technologies 
have  created  a  demand  for  secure  Unix  systems 
within  the  user  community. 

To. help  meet  the  demand  for  secure  Unix  systems, 
we  decided  to  port  Unix  to  LOCK  rather  than 
develop  a  new  OS.  This  is  very  appealing  from 
bo tli  a  developer  and  user  point  of  view  because 
of  the  large  amount  of  portable  Unix  applica¬ 
tions  that  already  exists. 


i.l  Background  of  the  Solution 

Traditional  approaches  to  providing  Multi-Level 
Secure  (MLS)  computing  systems  have  emphasized 
implementing  software  security  kernels  that  run 
when  the  target  processor  is  operating  in 
privileged  mode.  In  some  cases,  security  has 
been  provided  by  redesigning  the  OS.  These 
purely  software  approaches  to  providing  multi¬ 
level  security  have  four  primary  disadvantages: 


1  .  DECREASED  ASSURANCE  since  a  software  mal¬ 
function  could  cause  total  security  failure 

2.  DECREASED  PERFORMANCE  to  usually  unaccept¬ 
able  levels  because  of  the  high  overhead 
incurred  by  performing  the  security  access 
checks  in  software 

3.  LOSS  OF  EXISTING  APPLICATION  SOFTWARE 
because  of  the  extensive  redesign  of  the 
operating  system,  and 

4.  INABILITY  TO  FUNCTIONALLY  ENHANCE  the  OS 
without  requiring  expensive  and  time- 
consuming  re-verification  and  revaluation 
1 SAYD87 ] . 


‘Unix  is  a  trademark  ot  AT&T. 


The  LOCK  TCB  is  a  MLS  computing  system  currently 
being  prototyped  at  Honeywell  Secure  Computing 
Technology  Center.  It  has  been  designed  to  meet 
and  exceed  the  requirements  for  a  Class  A1  sys¬ 
tem  as  defined  in  the  DoD  Trusted  Computer  Sys¬ 
tem  Evaluation  Criteria  (the  Orange  Book) 
(TCSEC85) . 

LOCK  is  the  third  phase  of  a  continuing  project 
previously  called  the  Secure  Ada  Target  (SAT) , 
which  was  started  by  Honeywell  in  1982 .  The 
first  phase  of  the  SAT  program  (SAT-0)  resulted 
in  a  high-level  requirements  specification 
(HONE83) .  The  second  phase  (SAT-I)  resulted  in 
an  intermediate  specification  (HONE86) .  The 
third  phase  (SAT-11),  renamed  LOCK,  will  result 
in  a  detailed  design  specification  and  MLS  mini¬ 
computer  prototype  in  1990  (SAYD87) . 

1.1.1  The  LOCK  Solution  to  Multi-I.evel  Security 

The  LOCK  system  takes  a  hardware-oriented 
approach  to  providing  a  MLS  computing  system. 

This  approach  should  enable  the  system  to  over¬ 
come  the  disadvantages  associated  with  purely 
software  approaches, 

The  security  policy  of  the  system  is  enforced  by 
a  physically  separate,  multi-processor,  copro¬ 
cessing  unit  called  the  System-Independent, 
Domain-Enforcing,  Assured,  Reference  Monitor 
(SIDEARM) .  The  SIDEARM  has  its  own  processors, 
memory,  and  mass  storage.  Ail  security-related 
data  is  stored  on  the  SIDEARM  mass  storage  unit. 
Ail  security  policy  decisions  and  access  compu¬ 
tations  are  performed  by  the  SIDEARM. 

The  physical  separation  of  the  protection- 
critical  from  the  non  protection-critical  ele¬ 
ments  in  the  LOCK  system  makes  it  physically 
impossible  for  a  U3er  process  to  access  or 
tamper  with  the  SIDEARM  firmware  or  its  data, 
giving  the  LOCK  system  a  high  degree  of 
assurance . 

The  LOCK  host  processor  provides  TCB-mediated 
resource  management  and  computing  power  for  U3er 
applications.  Since  it  performs  no  security 
access  checks,  the  performance  degradation 
imposed  on  the  system  by  the  security  mechanisms 
should  be  minimal. 


The  results  reported  In  sections  1.0  through  4.0 
were  supported  by  National  Computer  Security 
Center  contract  MDA904-87-C-6011 . 
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The  security  functionality  provided  by  the 
SIDEARM  is  generic  in  nature,  and  largely 
independent  of  the  characteristics  of  the  host 
processor.  The  security  policy  that  the  SIDEARM 
enforces  is  configured  through  the  use  of  spe¬ 
cial  administrative  tools  at  system  generation 
time.  Virtually  any  security  policy  can  be 
defined  to  meet  the  needs  of  an  installation. 

Other  than  the  physical  hardware  connection 
between  the  SIDEARM  and  the  bus  of  the  host  pro¬ 
cessor,  the  SIDEARM  is  also  mechanically 
independent  of  the  host  architecture.  A  funda¬ 
mental  design  goal  of  the  SIDEEARM  was  to  design 
it  in  such  fashion  as  to  allow  it  to  be  ported 
to  other  non-LOCK  systems. 

The  LOCK  OS  will  not  be  responsible  for  enforc¬ 
ing  the  security  policy  of  the  system,  and 
therefore,  it  will  not  be  part  of  the  TCB  and 
not  have  to  be  verified  or  evaluated  when  it  is 
updated.  Further,  we  make  the  assumption  that 
the  OS,  and  other  non-TCB  software  for  that 
matter,  are  hostile  programs  that  will  attempt 
to  violate  the  security  policy  of  the  system, 
As  a  consequence  of  this  assumption,  we  follow  a 
least-privilege  design  philosophy  for  all  LOCK 
software  and  rely  heavily  upon  Type  Enforcement 
(see  subsection  2.2.2)  to  limit  the  objects 
application  may  access. 

Since  Unix  is  not  part  of  the  TCB,  we  will  not 
have  to  modify  it  to  provide  security  policy 
enforcement  mechanisms.  These  capabilities  are 
provided  by  the  underlying  TCB. 

We  do  plan  to  extend  the  Unix  interface  in  a 
non-intrusive  manner  to  make  the  MLS  features 
(e.g,  ACLs)  of  the  LOCK  TCB  available  to  users 
and  applications.  With  the  implementation 
approach  we  have  developed,  we  should  be  able  to 
maintain  a  great  deal  of  compatibility  with  the 
SVID  and,  hence,  with  the  existing  base  of  Unix 
applications . 


1.2  The  Study  Goals  and  Results 

During  1987,  we  performed  a  study  of  the  Unix 
kernel  to  determine  if  <t  could  be  (relatively 
easily)  ported  to  the  LOCK  system,  and  if  so, 
determine  what  the  effect  on  the  interfaces 
would  be.  To  enable  us  to  determine  if  it  would 
be  worthwhile  to  port  Unix,  we  established  the 
following  research  goals: 


•  The  number  of  modifications  to  the  Unix  ker¬ 
nel  should  not  be  extensive. 

•  The  TCB  could  not  be  modified  to  "tailor"  it 
to  running  Unix. 

•  Unix  had  to  be  able  to  service  many  con¬ 
current  users  running  at  different  security 
levels  without  becoming  part  of  the  TCB. 

•  The  file  system  had  to  be  able  to  manage  data 
at  different  security  levels  requiring 
trusted  servers  and  without  introducing 
covert  channels. 

e  The  resultant  system  must  maintain  a  maximum 
compatibility  with  the  SVID. 

The  results  of  our  study  indicate  that  these 
goals  can  be  met.  The  application  visible 
interface  to  the  LOCK  implementation  of  Unix 
(LOCK/ix)  is  nearly  identical  to  that  of  a  stan¬ 
dard  implementation  of  Unix  System  V.  The  secu¬ 


rity  policy  enforced  by  the  underlying  LOCK  TCB 
should  have  little,  if  any,  impact  on  the  major¬ 
ity  of  existing  Unix  applications. 

We  feel  one  major  result  of  the  study  is  our 
approach  for  implementing  an  untrusted  file  sys¬ 
tem  (see  section  4.0)  that  will  manage  the 
multi-level  data.  Internally,  our  file  system 
implementation  will  be  quite  different  than  in  a 
standard  Unix  kernel.  However,  users  and  appli¬ 
cations  should  not  notice  the  differences. 

Our  file  system  design  was  originally  intended 
to  support  LOCK/ix.  However,  we  feel  that  it  is 
general  enough  that  it  can  be  used  to  support 
other  (non-Unix)  LOCK  applications,  or  be 
applied  to  other  non-LOCK  TCBs  as  well. 

1.3  Overview  of  the  LOCK  Architecture 

The  LOCK  system  consists  of  two  computing  units: 
the  SIDEARM  and  the  host  processor.  The  major¬ 
ity  of  the  TCB  functionality  resides  in  the 
SIDEARM,  whose  firmware  coordinates  with  a  small 
(TCB)  software  kernel  (the  Supervisor)  that  runs 
on  the  host  processor. 

The  resultant  LOCK  TCB  provides  low-level  ser¬ 
vices  for  subject,  object,  and  dev. ce  manage¬ 
ment.  The  TCB  is  restricted,  for  r^ntens  of 
verifiability,  to  minimum  functionality.  It  is 
intended  to  support,  not  replace,  traditional  OS 
services,  such  as  a  hierarchical  file  system. 

The  Supervisor  (see  Figure  1)  functions  as  a 
low-level  resource  manager,  and  provides  an 
application  visible  interface  to  the  TCB' s  capa¬ 
bilities.  The  Kernel  Extensions  are  a  set  of 
verified,  security-relevant  utilities  whose 
capabilities  cannot  be  provided  by  the  SIDEARM 
in  a  generic  fashion. 
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1.3.1  The  SIDEARM 

The  SIDEARM  implements  what  is  called  the  Refer¬ 
ence  Monitor  (RM)  concept  (see  Figure  2) .  In 
general,  an  RM  can  be  thought  of  as  a  guard 
between  people,  and  the  information  they  would 
like  to  access.  There  are  three  important  cri¬ 
teria  for  an  RM: 


1.  It  must  always  be  invoked. 

2.  It  must  be  verified  to  be  correct  (i.e., 
properly  enforce  the  security  policy  of  the 
system) . 
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3.  It  must  be  unbypassable . 

4.  It  must  be  tamperproof. 


The  LOCK  hardware-oriented  approach  (see  Figure 
3)  provides  a  good  match  to  the  RM  mode.1. 
[SAYD87.1  . 


Reference  Monitor  Concept 


Reference  Monitor 


A  Reference  Monitor  Mutt  Be 

1.  Always  Invoked 

2.  Verfied  Correct 

3.  Unbypetteble 

4.  Tamperproff 

Figure  2 


Security  Coprocessor  Component  Approach 


The  portion  of  the  Supervisor  that  runs  in  the 
privileged  mode  is  only  that  code  which  is 
forced  there  by  the  hardware,  such  as  the  inter¬ 
rupt  handlers.  Other  code,  such  as  the  subject 
scheduler,  runs  in  user  mode  of  the  host  proces¬ 
sor  . 


Reference  Monitor  in  LOCK 


Ha/dwara  Advanl*Q*t 

1.  HfQh  Auuano* 

2.  Ftouoftftbtt  P*rterminc# 

3.  Application  Portability 

4.  Functionality 

Figure  4 

All  code  that  runs  in  privileged  mode  will  be 
placed  in  Read-Only  Memory  (ROM)  that  is 
addressable  only  when  the  processor  is  running 
in  privileged  mode,  thereby  making  it  tamper¬ 
proof.  Other  software,  such  as  the  OS,  will  run 
in  user  mode  on  the  host  processor. 


How  A  Security  Coprcinsssar  Meeti  Reference  Monitor  Criteria 

1 .  Always  Invoked  ■  No  Wey  To  Bynau 
S  Verified  Correct  ■  Simpler.  Machine  Independent 
3.  Tamperproof  -  No  Way  To  Attar*  Sacurfty  Coprooeuot 


Figure  3 

When  the  system  is  booted,  the  SIDEARM  is  booted 
and  initialised  before  the  host  processor  begins 
to  run  and  continues  to  run  until  the  system  is 
3hut  down.  All  security-related  data  and  most 
of  the  security  functionality  is  implemented  in 
the  SIDEARM,  thus  making  it  passible  to  verify 
that  it  ia  correct.  And  finally,  since  the 
SIDEARM  Is  physically  separate  (see  Figure  4) 
and  maintains  its  own  memory  and  mass  storage, 
there  i3  no  (physical)  way  for  a  user  process  to 
tamper  with  its  firmware  or  data.  It  is 
unbypas3able  since  it  is  the  SIDEARM,  and  not 
the  Host  processor,  that  has  exclusive  control 
over  the  Memory  Management  Unit  (MMU)  . 

1.3.2  The  Host  Processor 

As  mentioned  previously,  a  small  software  kernel 
(which  is  part  of  the  TCB)  run9  on  the  host  pro¬ 
cessor.  This  software  kernel  is  responsible  for 
preserving,  and  not  enforcing,  the  security  pol¬ 
icy  of  the  system  by  performing  correct,  low- 
level  resource  management.  This  software  ker¬ 
nel,  called  the  Supervisor,  consists  of  code 
that  runs  in  both  privileged  and  user  mode  of 
the  host  processor. 


2.0  Overview  of  the  LOCK  Security  Model. 

The  LOCK  TCB  enforces  a  MLS  policy.  The  policy 
is  enforced  by  mediating  access  between  sub¬ 
jects,  the  active  entities  of  the  system,  and 
objects,  the  inactive  entities  of  the  system. 

To  enforce  this  policy,  the  SIDEARM  maintains  a 
large  database  called  the  Global  Object  Table 
(GOT) .  Each  time  a  subject  or  object  is 
created,  it  is  assigned  a  unique  identifier 
(UID) .  A  GOT  entry  is  then  created  for  the  new 
entity  where  the  UID  is  used  as  the  primary  key. 
A  GOT  entry  will  contain  additional  information 
such,  a u  the  level  and  the  creator. 

The  LOCK  TCB  provides  Discretionary  Access  Con¬ 
trol  (DAC)  and  Mandatory  Access  Control  (MAC) 
mechanisms  to  enforce  the  system's  security  pol¬ 
icy,  In  order  for  a  subject  to  be  granted 
access  to  an  object,  the  request  must  be  allowed 
by  both  the  DAC  and  MAC  mechanisms  of  the  sys¬ 
tem. 

2.1  Disc. ationary  Access  Control  Policy 

A  DAC  policy  is  discretionary  because  its 
administration  is  up  to  the  discretion  of  the 
system  users.  The  LOCK  TCB  provides  Access  Con¬ 
trol  Lists  (ACLs)  as  the  mechanisms  for  provid¬ 
ing  DAC, 

ACLs  allow  a  user  to  specify,  for  each  named 
object  he  is  authorized  to  control,  a  list  of 
named  individuals  and  a  list  of  groups  of  named 
individuals  and  their  respective  modes  of  access 
to  the  object.  Additionally,  for  each  named 
object,  the  authorized  user  may  specify  a  list 
of  named  individuals  and  a  list  of  groups  of 
named  individuals  for  which  no  access  to  the 
object  is  to  be  given.  The  currently  supported 
modes  of  discretionary  access  are  read  (r), 
write  (w),  execute  (x),  and  null  In). 

One  aspect  of  the  LOCK  DAC  policy  that  should  be 
noted  is  the  fact  that  there  is  no  concept  of 
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object  ownership,  or  any  special  privileges 
associated  with  object  ownership.  Rather,  the 
security  policy  the  system  enforces  is  config¬ 
ured  to  indicate  who  can  control  (change  the  ACL 
of)  objects  of  a  spocific  type.  This  typically 
will  be,  but  is  not  limited  to,  the  creator  of 
an  object. 

2.2  Mandatory  Access  Control  Policy 

A  MAC  policy  is  mandatory  because  it  is  always 
enforced  by  the  system.  Unlike  a  DAC  policy, 
the  system  users  have  no  say  in  how  the  policy 
is  administered.  The  LOCK  MAC  policy  is 
enforced  by  Labeled  Security  Protection  and  Type 
Enforcement  mechanisms. 

2.2.1  Labeled  Security  Protection 

The  LOCK  TCB  enforces  Labeled  Security  Protec¬ 
tion  as  required  by  the  Orange  Book.  The  policy 
is  enforced  over  all  system  resources  (e.g,, 
subjects,  objects,  and  I/O  devices)  that  are 
directly  or  indirectly  accessible  by  subjects 
external  to  the  TCB. 

The  LOCK  TCB  maintains  a  SXDEARM-residerit  data 
structure  that  is  a  partially  ordered  set 
(POSet)  of  al.l  security  levels  (combination  of 
one  hierarchical  level  and  a  set  of  non- 
hierarchical  categories)  defined  in  the  system. 

The  LOCK  POSet  is  a  generalization  of  the  Orange 
Book  concept  of  a  security  lattice.  The  differ¬ 
ence  them  is  the  fact  that  the  POSet  has  no 
lowest  or  highest  bound.  For  example,  two  lev¬ 
els  may  be  equal  in  classification  but  have  a 
different  (and  incompatible)  category  set  (e.g. 
TOP_SECRET.A  and  TOP_SECRET.B) .  Hence,  one  can 
not  be  said  to  be  "higher"  than,  or  dominate  the 
ether . 

When  a  subject  or  object  is  created,  it  is 
assigned  one  of  the  levels  (nodes)  from  the 
POSet.  Access  is  then  computed  using  the  level 
of  the  subject  requesting  access  and  the  level 
of  the  object  being  accessed  in  the  following 
manner : 


•  To  read  an  object,  the  level  of  the  subject 
must  dominate  the  level  of  the  object  (the 
Simple  Security  Property)  . 

•  To  write  an  object,  the  level  of  the  subject 
must  be  dominated  by  the  level  of  the  object 
(the  ‘-Property) . 


As  used  in  the  rules  aoove,  the  term  dominate 
means  greater  than  or  equal  to.  For  each 
required  access  computation,  the  POSet  is  con¬ 
sulted  to  determine  if  one  level  dominates 
another . 

2.2.2  Type  Enforcement 

Type  enforcement  is  a  mechanism  that  is  unique 
to  the  LOCK  TCB.  Hot  required  by  the  Orange 
Book,  it  is  this  mechanism  that  will  (in  part) 
allow  the  LOCK  TCB  to  exceed  the  Orange  Book 
Class  Ai  requirements.  Type  enforcement  is 
based  on  two  attributes: 


•  The  domain  of  execution  of  a  subject. 

•  The  type  of  the  object  a  subject  is  attempt¬ 
ing  to  access. 


A  domain  is  similar  in  concept  to  rings  in 
ringed  architecture  machines.  Unlike  rings, 
though,  there  is  no  hierarchical  relationship 
between  domains.  Moving  from  one  domain  to 
another  does  not  necessarily  imply  an  accumula¬ 
tion  of  increasing  system  privilege.  Rather, 
each  domain  has  a  set  of  privileges  different 
from  other  domains. 

To  represent  the  domains  and  the  privileges 
allowed  in  them,  the  TCB  maintains  a  SIDEARM- 
resident  data  structure  called  the  Domain  Table. 
It  contains  the  following  information: 


•  Thu  UID  of  the  domain. 

•  The  human-readable  name  of  the  domain, 

•  A  list  of  special  privileges. 

•  A  list  of  domains  to  which  other  subjects  in 
the  named  domain  have  access  to,  and  the 
modes  of  access  (create  a  subject,  destroy  a 
subject,  signal  a  subject,  etc.)  permitted. 

The  special  permissions  that  are  allowed  in 
domains  are  the  ability  for  a  subject  to  take 
exception  to  the  DAC  and/or  the  Labeled  Security 
Protection  mechanisms  of  the  system.  Since  it 
is  the  type  enforcement  mechanism  that  allows  a 
subject  to  have  these  special  privileges,  a  sub¬ 
ject  may  never  take  exception  to  the  type 
enforcement  rules  of  the  system. 

Tha  domain  of  execution  is  an  attribute  of  a 
subject  that  remains  constant  throughout  its 
lifetime.  In  other  words,  a  subject  can  only 
execute  in  one  domain. 

All  objects  have  a  typo  associated  with  them. 
The  concept  of  type  fs  similar  in  nature  to 
types  in  high  level  programming  languages.  The 
TCB  restricts  operations  on  objects  of  specific 
types  based  on  the  domain  of  execution  of  the 
subject  attempting  the  access. 

To  represent  object  types  and  the  operations 
allowed  on  them,  the  TCB  maintains  a  SIDEARM- 
resident  data  structure  called  the  Type  Table. 
It  contains  the  following  information: 


•  The  UID  of  the  type. 

•  The  human-readable  type  name. 

•  Allowable  object  sizes  (minimum  and  maximum) . 

•  List  of  domains  from  which  subjects  have 
access  to  objects  of  the  named  type,  and  the 
modes  of  access  (read,  write,  etc.)  permit¬ 
ted. 

•  Default  ACL. 


When  a  subject  requests  ,ccess  to  (or  attempts 
to  create)  an  object,  the  TCB  consults  the 
Domain  and  Type  Tables  to  determine  if  the 
access,  based  on  the  domain  of  execution  and  the 
object  type,  is  allowed. 

Both  the  Domain  Table  and  Type  Table  are  ini¬ 
tialized  at  system  generation  time  by  the  System 
Security  Officer  (SSO)  and  are  inaccessible  to 
user  processes.  It  is  thi3  ability  to  configure 
the  Domain  and  Type  Tables  that  enables  the  LOCK 
to  support  virtually  any  security  policy  an 
installation  desires. 
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As  mentioned  earlier,  type  enforcement  can  be 
used  to  grant  special  privileges.  For  example, 
it  may  be  necessary  to  implement  an  application 
that  is  allowed  to  downgrade  files.  The  list  of 
special  privileges  in  the  Domain  Table  is  used 
to  grant  such  privileges.  The  Type  Table  is 
used  to  restrict  which  object  types  can  be  read 
and  written  in  the  downgrade  process. 

Type  enforcement  is  also  useful  for  integrity 
reasons .  For  example,  the  system  may  grant  sub¬ 
jects  running  in  a  system  administration  domain 
read  and  write  access  to  objects  of  type 
username_f ile .  Subjects  running  in  the  OS 
domain  may  be  granted  only  read  access  to 
objects  of  type  username_.file .  With  the  Domain 
and  Type  Tables  established  in  this  fashion,  the 
system  will  prevent  unauthorised  modification 
(integrity)  of  objects  of  the  type  password 
file. 

The  type  enforcement  mechanism  can  be  used  to 
support  a  variety  of  integrity  models  such  as 
the  Clark-Wilson  (CLARK87J  model,  and  as 
described  in  (BOEB85] ,  the  Biba  [BXBA75J  modal 
as  well. 

2.3  Subjects 

The  basic  execution  (active)  entity  in  LOCK  is 
the  subject.  A  subject  is  a  process  that  exe¬ 
cutes  in  a  particular  security  context.  The 
security  context  comprises  the  level  of  the  sub¬ 
ject,  the  domain  of  execution,  and  the  user  on 
whose  behalf  the  subject  is  executing.  In  many 
ways,  a  subject  is  like  a  Unix  process)  it 
shares  the  processor  with  other  subjects  through 
timeslicing,  it  has  access  to  a  "file  system" 
that  other  subjects  also  have  access  to,  it  can 
open  and  operate  on  "files, 11  and  it  has  limited 
capabilities  for  communicating  with  other  sub¬ 
jects  . 

There  are  some  notable  differences  between  sub¬ 
jects  and  Unix  procesaes.  There  are  no 
hierarchical  parent/child  relationships;  each 
subject  is  independent  of  the  subject  that 
created  it.  For  Unix  processes  with  the  user  ID 
of  superuser,  the  entire  system  is  accessible; 
there  is  no  corresponding  notion  of  superuser  in 
LOCK/ix.  Under  Unix,  multiple  processes  can  bs 
writing  to  the  process  control  terminal  simul¬ 
taneously;  LOCK  allows  only  one  subject  to  per¬ 
form  terminal  I/O  to  a  given  (process  control) 
terminal  at  a  time. 

All  subjects  have  associated  with  them  a  Subject 
Translation  Table  (STT) .  The  STT  contains  an 
entry  for  each  object  that  the  subject  hae 
opened  (see  Figure  5) .  In  LOCK/ix,  objeota  are 
used  to  represent  Unix  file  system  objects 
(file,  directories,  etc.),  text  segments  and 
data  segments,  process  stacks,  and  kernel  level 
data  structures.  The  STT  is  similar  in  nature 
to  the  Unix  per-user  open  file  table.  Each 
entry  in  the  STT  identifies  an  objsct  and  ths 
current  access  that  the  subject  has  to  it.  The 
STT  is  resident  in  the  host  processor'*  memory 
and  provides  the  first  level  of  address  transla¬ 
tion  for  the  MMU. 

Subjecte  within  the  LOCK  eyatem  ara  character¬ 
ized  by  the  following) 


e  Each  subject  is  uniquely  identified  within 
the  SIDEARM'*  security  database  (the  GOT)  by 
the  UID  tha  sidearm  assigned  to  it  when  it 
was  creatsd.  The  GOT  entry  represents  the 
security  context  of  the  subject. 


*  The  subject  manager  (within  the  host  resident 
portion  of  the  TCB)  maintains  a  data  struc¬ 
ture  called  the  Active  Subject  Table.  Each 
active  subject  within  the  system  is  uniquely 
identified  by  subject  manager  by  its  entry  in 
the  Active  Subject  Table. 

•  A  user  subject  may  exeoute  instructions  if 
and  only  if  th*  host  processor  is  operating 
in  user  mode.  (Only  TCB  subjects  may  operate 
when  the  Host  processor  is  in  privileged 
mode. ) 


User  subjects  are  created  as  a  result  of  a  TCB 
Create  Subject  request.  They  come  into 
existence  as  the  result  of  a  user  action,  per¬ 
form  their  function,  and  are  terminated  by  a  TCB 
Destroy  Subject  request  at  some  later  time. 
When  a  subject  is  destroyed,  the  subject  ceases 
to  exist  within  the  system.  All  objects  allo¬ 
cated  by  the  subject  (contained  within  its  STT) 
are  closed,  and  all  resources  (e.g.,  GOT  entry, 
memory,  etc.)  previously  allocated  to  the  sub¬ 
ject  are  released. 


Typical  LOCK/ix  Subject  STT 


LOCK/lx  Kernel  Text  Segment 

LOCK/lx  Kernel  Data  Segment 

LOCK/lx  Kernel  Stack  Object 

eh  Text  Segment 

ah  Data  Segment 

sh  Stack  Segment 

•  •  • 

emacsText  Segment 

emacs  Data  Segment 

emace  Stack  Segment 

File  1 

File  2 

•  •• 

Figure  5 


2.3.1  Relation  to  Unix  Virtual  Machines/Unix 

Processes 

The  differences  between  Unix  processes  and  LOCK 
subjects  strongly  influenced  the  way  Unix 
processes  are  rspresented  in  LOCK/ix.  To 
cleanly  support  Unix  process  mangement  func¬ 
tionality,  each  subject  represents  the 
equivalent  of  an  abstract  Unix  virtual  machine. 

To  provide  support  for  operating  systems  built 
on  top  of  th#  LOCK  TCB,  tl  well  a*  multitasking 
applications  such  as  an  Ada  run-tima  environ¬ 
ment,  a  oubject  has  periodic  software  interrupt, 
similar  to  a  timeslice  interrupt,  available  to 
it.  A  "beginning  timeslice"  signal  is  sent  to 
all  LOCK  subjects  from  the  TCB  when  they  begin 
to  execute  in  a  new  timeslice. 

To  take  advantage  of  this  feature,  a  subject 
must  enable  a  signal  handler,  in  muoh  the  same 
way  as  is  done  for  Unix  signal  handlers.  If  * 
subject  does  not  wish  to  take  advantage  of  this 
signal  and  does  not  define  a  handler  for  it,  tha 
signal  is  ignored  and  th*  subjeot  is  allowed  to 
run  without  the  knowledge  of  receipt  of  th#  eig- 
nal . 
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Unlike  the  Unix  signal  handling  mechanism,  the 
LOCK  signal  handling  mechanism  provides  to  the 
subject  its  context  (register,  stack  pointer, 
and  program  counter  values)  when  the  signal 
occurred.  There  is  no  way  for  a  subject  to  con¬ 
trol  the  frequency  of  this  signal.  The  fre¬ 
quency  of  occurrence  of  this  signal  is 
unpredictable . 

The  use  of  this  feature  allows  a  subject  to  per¬ 
form  its  own  process  multiplexing.  Each  subject 
can  run  its  own  process  (or  task)  multiplexing 
algorithm  to  provide  multiprocessing  support 
within  the  subject. 

2,4  Objects 

One  of  the  most  unusual  features  of  LOCK  (at 
least  for  those  accustomed  to  Unix)  is  that 
there  is  no  notion  of  external  files  of  or  a 
file  system;  instead,  there  are  objects. 
Oblects  are  containers  for  data  that  reside  in 

the  virtual  memory  and  can  be  (physically) 
stored  on  disk,  tape,  or  other  media  such  as 
optical  disk. 

All  objects  have  associated  with  them  a  set  of 
attributes  that  are  similar  in  nature  to  Unix 
file  attributes.  These  attributes  include  the 
object  type,  size,  security  level,  creator,  ACL, 
permanent  location,  and  the  present  location  (in 
main  memory) . 

Objects  are  a  generalization  of  a  segmented 
memory  system.  The  TCB  Open  Object  operation 
maps  an  object  into  the  virtual  address  space  of 
a  subject  and  returns  a  pointer  to  a  memory 
address.  Datum  with  an  open  object  can  be 
accessed  by  referencing  offsets  into  the 
object's  memory  range.  I/O  is  performed  on 
objects  by  modifying  the  contents  Of  memory 
addresses  in  the  open  object.  One  object  can  be 
open  by  multiple  subjects  simultaneously,  with 
the  object  mapped  to  different  virtual  addressos 
in  each  subject's  address  space. 

2.4.1  Relation  to  Unix  Virtual  Memory 

All  memory  that  a  subject  references,  even  the 
subject  itself,  consists  of  open  objects.  The 
virtual  memory  space  of  a  subject  is  the  union 
of  open  object  virtual  addresses.  LOCK  imposes 
a  limit  on  the  number  of  open  objects  a  subject 
is  allowed,  which  is  currently  256.  The  maximum 
size  of  on  object  is  )6Mbytes. 

Disk  I/O  is  performed  by  LOCK  without  explicitly 
doi’ g  I/O  (i.e.,  issuing  a  command  to  a  device 
driver) .  The  MMU  provides  the  mapping  between 
memory  references  and  modifications  and  physical 
I/O,  If  a  piece  of  an  open  object  that  has  been 
paged  out  to  disk  is  referenced,  the  MMU  causes 
the  appropriate  piece  of  the  object  to  be 
brought  into  memory.  To  an  application,  the 
entire  contents  of  an  object  appoar  to  be  in 
memory  when  an  object  is  opened,  and  the  con¬ 
tents  disappear  when  the  object  is  closed. 

Referencing  a  memory  address  that  is  not  mapped 
to  an  open  object  generates  a  bus  error.  A  bus 
error  will  be  interpreted  by  the  TCB  as  an 
attempt  to  violate  the  security  policy  of  the 
system  and  cause  the  termination  of  the  offend¬ 
ing  subject.  Although  termination  of  the  sub¬ 
ject  seems  to  be  a  bit  harsh,  under  similar 

circumstances  Unix  would  terminate  the  offending 
process  and  generate  a  "core  dump". 


LOCK  object  operations  are  analogous  to  Unix 
memory  management  functions  in  many  ways.  Open¬ 
ing  an  object  is  similar  to  allocating  a  region, 
in  order  to  obtain  memory  for  a  process. 
Objects  can  expand  and  shrink,  as  can  regions, 
Open  objects  are  memory  regions  associated  with 
each  process. 

2.4.2  Relation  to  Unix  File  System  and  Files 

Objects  provide  the  foundation  for  building  a 
file  system  that  will  appear  to  operate  similar 
to  Unix.  However,  from  a  programming  stand¬ 
point,  object  operations  are  quite  different 
than  file  I/O  operations. 

The  LOCK/ix  kernel  is  responsible  for  providing 
the  functional  bridge  between  the  LOCK  TCB  and 
Unix  applications,  it  provides  the  functional¬ 
ity  necessary  to  support  a  Unix  file  system 
built  on  top  of  LOCK  objects. 

File  creation  requires  that  an  object  be  created 
and  cataloged  Into  the  file  system  in  the 
correct  directory,  with  the  inode  table  provid¬ 
ing  the  linkage  between  physical  storage  and 
external  appearance.  Open  and  close  operations 
logically  perform  the  same  function  in  both  LOCK 
and  Unix,  making  the  objects  "known"  and  "unk¬ 
nown"  to  an  executing  process. 

LOCK/ix  will  map  the  Unix-style  access  opera¬ 
tions  into  their  LOCK  counterparts.  Unix-style 
I/O  operations  will  be  mapped  into  open  object 
references  and  updates.  File  deletion  removes  a 
reference  to  an  object  from  the  file  system,  and 
if  there  are  no  references  remaining,  the  object 
will  be  deleted  from  the  file  system. 

3.0  Process  Management  in  LOCK/ix 

The  Unix  process  management  services  provide 
process  creation  and  deletion,  program  execu¬ 
tion,  and  synchronization  between  related 
proceoses.  The  Unix  model  of  process  creation, 
using  the  fork()  operation,  enforces  parent- 
child  relationships  between  processes  and 
ensures  that  a  child  process  is  initially 
created  to  be  an  exact  copy  of  its  parent.  The 
Unix  model  of  program  execution,  using  the 
execO  operation,  provides  for  the  inheritance 
by  the  new  program  of  part  of  the  environment  of 
the  process  that  executes  the  program. 

In  contrast  to  Unix  in  which  all  user  processes 
are  managed  and  coordinated  by  a  single  kernel 
entity,  the  LOCK/ix  implementation  encapsulates 
the  management  of  processes  for  each  LOCK/ix 
login  session  within  a  single  LOCK  subject  (see 
Figure  6) .  Each  LOCK/ix  subject  contains  an 
(virtual)  instance  of  the  Unix  kernel  that 
manages  only  the  user  processes  associated  with 
its  login  session.  The  LOCK/ix  kernel  is  in 
reality  a  shared  text  segment  that  is  used  by 
all  LOCK/ix  subjects.  However,  at  any  point  in 
time,  the  kernel  only  "knows"  about  the  single 
LOCK/ix  subject  that  it  is  currently  servicing. 

Although  this  approach  to  process  management  is 
a  bit  unusual,  it  does  provide  sn  implementation 
of  fork()  and  exec()  that  is,  from  the  viewpoint 
of  an  executing  process,  compatible  with  Unix. 
The  set-user-ID  modes  of  file  execution  are  par¬ 
tially  supported.  They  effect  only  the  user-IDs 
of  an  individual  process,  and  the  the  user-ID  of 
the  containing  subject, 
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LOCK/lx  Address  Space  Organization 


Figure  8 


Theca  is  a  problem  that  is  encountered  when  try¬ 
ing  to  support  Unix  sat-user-lt)  applications  in 
a  MLS  environment.  Unix  maintains  both  a  real- 
user-ID  that  indicates  who  logged  on,  and  an 
ef faetive-user-ID  that  indicates  on  whose  behalf 
the  process  is  executing,  for  each  active  pro¬ 
cess.  Under  normal  circumstances,  these  user- 
IDs  represent  the  same  individual.  When  the 
process  is  an  Instance  of  a  set-uid  application, 
the  effect Ive-user-id  of  the  process  is  set 
equal  to  the  owner-id  of  the  set-uid  applica¬ 
tion. 

Unix  always  uses  the  effective-user-id  of  a  pro¬ 
cess  for  computing  access  rights.  Running  a 
set-user-XD  program  has  the  effect  of  tem- 
porariiy  granting  the  owner's  access  rights  to 
the  user  of  the  set-user-ID  application.  In 
contrast  to  this,  the  LOCK  TCB  maintains  only 
one  user-ID  for  each  active  subject.  A  LOCK 
subject  user-ID  and  a  process  real-user-ID  are 
the  same  indivi iual  (the  person  who  is  actually 
logged  on) . 

The  LOCK  TCB  does  r.ot  support  this  notion  of 
granting  temporary  access.  To  compute  access, 
the  LOCK  TCB  will  always  use  (the  equivalent  of) 
the  real-user-id  of  a  process.  As  a  consequence 
of  this,  our  current  design  does  not  provide 
fully  compliant  support  for  set-user-ID  applica¬ 
tions. 

We  are  currently  investigating  several  alterna¬ 
tive  approaches  to  solving  this  problem  (see 
section  5.0)  .  Since  the  Unix  user  community 
appears  to  have  a  strong  desire  to  continue  to 
run  set-user-ID  applications,  our  current  design 
will  most  likely  be  criticized  as  providing 
unacceptable  support  for  set-user-id  applica¬ 
tions  . 

There  are  some  within  the  computer  security  com¬ 
munity  who  argue  that  a  capability  such  as  set- 
user-ID  should  not  be  provided  by  A1  systems. 
This  is  a  debate  that  is  likely  to  continue  for 
many  years  to  come.  Our  feeling  is  that  is  the 
existing  Unix  file  protection  mechanisms,  snd  in 
particular  the  set-user-id  capability,  are 
really  integrity  mechanisms.  If  a  method  can  be 
devised  to  support  a  fully  functional  oet-user- 
id  capability  in  a  secure  manner,  we  see  no 
disadvantage  to  doing  so. 


3.1  Memory  Management 

Unix  kernel  memory  management  functions  provide 
user  processes  with  an  expandable  data  area  that 
can  be  used  for  dynamic  heap  allocation.  The 
heap  allocation  algorithms  are  supplied  by  the 
run-time  library  and  provide  a  generalized 
memory  block  allocation  scheme  to  user  programs. 
They  call  on  the  kernel  to  expand  the  data  seg¬ 
ment  of  a  user  process  as  needed  to  incroase  the 
pool  of  memory  that  is  available  for  allocation. 

Although  not  explicitly  visible  at  the  user  pro¬ 
gram  interface,  Unix  memory  management  also  nor¬ 
mally  enforces  protection  over  the  address  space 
of  a  user  process  from  access  by  other 
processes.  The  address  space  of  the  kernel  is 
also  protected  from  access  by  user  processes. 

These  capabilities  are  dependent  on  the  charac¬ 
teristics  of  the  MMU.  In  LOCK  it  is  the  TCB, 
and  not  LOCK/ix,  that  has  explicit  control  over 
the  MMU.  As  a  consequence  of  this,  such  protec¬ 
tion  cannot  be  provided  by  LOCK/ix. 

The  LOCK/ix  kernel  manages  memory  via  calls  to 
the  TCB  storage  manager.  The  physical  alloca¬ 
tion  of  memory  is  replaced  by  requests  to 
create,  delete,  open,  close,  and  expand  the  LOCK 
objects  that  compose  the  address  space  of  user 
processes.  Each  user  process  within  the  subject 
is  assigned  a  text  segment,  data  segment,  and 
stack  object  by  the  kernel  which  are  open  as 
long  as  the  process  is  executing.  When  a  pro¬ 
cess  terminates,  these  objects  are  closed  and 
deleted  by  the  kernel. 

Expansion  of  the  data  segment  is  implemented  by 
calling  the  TCB  storage  manager  request  Expand 
Object.  This  TCB  request  automatically  handles 
physical  relocation  of  the  object  if  needed  and 
zeros  the  newly  allocated  space  for  LOCK/ix. 

Expansion  of  the  stack  object  is  implemented  by 
a  special  LOCK/ix  system  call,  which  is  used  to 
request  that  the  stack  of  the  calling  process  be 
extended.  This  requires  that  the  compiler  gen¬ 
erate  a  stack  overflow  check  as  part  of  every  C 
function's  entry  preamble  code.  Although  rela¬ 
tively  inefficient,  this  method  of  automatic 
stack  growth  is  used  on  many  standard  Unix 
machines  that  have  no  hardware  support  for  stack 
overflow  detection  in  the  MMU. 

4.0  The  LOCK/ix  File  System  Design 

The  file  and  I/O  system  is  one  of  the  principal 
components  of  Unix.  Conceptually,  it  provides  a 
uniform  method  for  performing  I/O,  by  mapping 
ali  I/O  into  file  I/O.  Applications  can  operate 
in  the  same  manner  whether  I/O  is  being  done  to 
a  terminal,  a  file,  a  interprocess  communication 
pipe,  or  a  physical  device. 

Due  to  the  nature  of  the  Unix  file  system,  many 
applications  tend  to  be  highly  I/O  intensive. 
If  the  file  system  does  not  work  as  expected, 
the  effect  on  applications  ported  to  LOCK/ix 
could  outweigh  the  effort  to  develop  the 
software  from  scratch.  A  fundamental  design 
goal  of  LOCK/ix  was  to  make  the  file  system 
appear  as  much  like  the  Unix  file  system  as  pos¬ 
sible. 

In  our  design  of  the  file  system  structure,  a 
separate  file  system  at  each  security  level  is 
supported.  An  inode  table  for  each  file  system 
is  stored  in  an  object  that  ia  equal  in  level  to 
the  file  system  it  represents.  Directory 
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entries  will  map  inodas  to  filas  as  is  dona  in 
axiating  Unix  implementations . 

The  major  difference  between  the  LOCK/ix  file 
system  structure  and  the  standard  Unix  file  sys¬ 
tem  structure  is  that  directories  with  the  same 
name  may  exist  at  multiple  levels.  The  direc¬ 
tories  at  all  observable  levels  are  logically 
overlaid  to  produce  a  virtual  directory.  To  a 
user  process,  it  will  not  be  apparent  that  an 
observable  directory  has  been  constructed  from 
multiple  file  systems,  The  level  at  which  the 
user  process  is  executing  will  determine  which 
files  are  visible  in  its  view  of  the  file  sys¬ 
tem. 

To  avoid  the  need  for  trusted  code,  a  directory 
is  restricted  to  containing  only  entries  that 
are  at  the  same  level  at  the  directory.  How¬ 
ever,  if  the  same  directory  exists  at  several 
levels,  each  containing  files,  applications  are 
given  the  illusion  that  the  (virtual)  directory 
contains  files  at  multiple  levels.  To  support 
this  capability,  only  the  directory  paths  are 
duplicated,  not  the  files. 

Figure  7  presents  a  simple  two-level  file  system 
that  contains  a  UNCLASS  file  system  and  a  SECRET 
file  system.  A  LOCK/ix  process  running  at 
UNCLASS  would  see  the  files  oat  and  Is  in  the 
/bin  directory.  A  SECRET  process  would  see 
those  two  files  (as  read-only),  and  in  addition, 
the  file  magic. 

Initial  Two  Level  File  System  Example 
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Figure  7 

LOCK/ix  will  perform  the  logical  combination  of 
the  file  systems  from  multiple  levels  to  pressnt 
ths  illusion  thst  there  ie  a  lingla,  multi-lsvel 
fils  systsm.  The  files  contained  in  the  UNCLASS 
file  system  thst  the  process  running  st  SECRET 
can  obaarva  are  of  course  not  writable.  The 
view  of  the  file  system  presented  to  e  SECRET 
process  will  contain  the  SECRET  file  system 
overlaid  on  top  of  the  UNCLASS  file  system. 


An  process  running  at  UNCLASS  will  have  no  way 
of  determining  the  existence  of  anything  in 
SECRET  (or  anything  above  UNCLASS  for  that 
matter) .  The  security  policy  enforced  by  LOCK 
deny  access  to  any  file  system  objects  above  the 
level  of  UNCLASS. 

It  should  be  noted  that  the  LOCK  TCB  enforces 
the  protection  of  objects  so  that  even  malicious 
programs  osn  not  affect  the  data  contents  ol  an 
object  unless  the  subject  has  write  access  to 
the  object. 

The  LOCK/ix  design  provides  what  appears  to  be 
the  beet  compromise  between  Unix  compatibility 
and  the  required  MLS  functionality.  Ke  have 
developed  a  design  thst  should  hsve  the  "look 
and  feal"  of  Unix.  Each  file  system  is  com¬ 
pletely  isolated  from  the  file  systems  st  othsr 
levels. 

The  ooncept  of  virtual  directoriea  could  also  be 
applicable  to  a  conventional,  unsecure  networked 
Unix  environment.  If  file  systems  resided  on 
multiple  machines,  some  with  the  same  directory 
path  namaa,  virtual  directories  could  be 
crested.  The  issue  of  whioh  network  machine  a 
file  resided  on  would  no  longer  be  significant. 

4.1  Path  Inheritance 

In  order  to  support  virtual  directories,  a 
method  ie  needed  whereby  files  can  be  created  at 
the  current  level  if  the  directory  path  exists 
only  at  a  lower  level,  It  would  be  incompatible 
with  Unix  to  allow  a  process  to  create  a  direc¬ 
tory  path  that  already  exists.  LOCK/ix  will 
automatically  a  areata  directory  path  at  the 
subject's  level,  when  required,  to  fulfill  a 
create  request.  We  call  this  operation  path 
inheritance . 

As  in  Unix,  an  attempt  to  create  a  file  in  a 
directory  that  does  not  exist,  or  is  not  observ¬ 
able,  will  fail.  If  the  directory  exists  at  the 
subject's  current  level,  no  special  processing 
is  required  to  fulfill  a  create  request.  Only 
when  components  of  the  required  path  do  not 
exist  at  ths  subjsct's  current  level  (but  exist 
at  a  lower,  observable  level)  does  LOCK/ix  need 
to  create  them.  The  creation  of  path  components 
at  the  current  level  ia  handled  in  s  manner  that 
is  transparsnt  to  user  processes. 

A  good  analogy  to  this  operation  is  s  virtual 
mamory  system.  The  working  set  is  at  first  very 
small,  containing  only  the  top-level  path  com¬ 
ponents.  As  files  era  crested,  as  with  pages 
not  in  memory,  a  "fault"  occurs  and  the 
appropriate  pageB  are  brought  in  from  disk,  or 
in  this  case,  path  components  are  created. 
Eventually,  a  stable  working  set  is  established 
that  handles  most  references,  for  aither  virtual 
memory  or  ths  LOCK/ix  file  system.  The  differ¬ 
ence  is  that  ths  directory  paths  created  are 
permanent  and  will  continue  to  exist  in  ths  file 
system.  There  is  no  wey  a  process  can  determine 
thst  a  directory  path  was  inherited. 

If  directory  entries  are  created  with  names  that 
(unknowingly  and  unintentionally)  match  those  et 
a  higher  level,  the  higher  level  virtual  direc¬ 
tory  view  will  contain  all  the  files,  including 
multiple  files  with  the  same  name.  The  lower 
level  view  will  consist  of  only  those  files  end 
subdirectories  that  exist  at  the  lower  level. 

A  deeign  issue  that  ia  currently  open  is  how  to 
handle  thie  potential  name  collision.  If  ident¬ 
ically  named  files  exist  at  multiple  levels  in  a 
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directory,  the  higher  level  processes  will  need 
e  way  to  determine,  or  specify,  which  file  gets 
accessed.  An  extension  to  the  namei  routine, 
which  performs  name  to  inode  mapping,  is  planned 
for  the  future.  This  extension  will  allow  a 
process  to  specify  the  level  of  a  file  to  be 
opened.  Naturally,  this  capability  will  be  res¬ 
tricted  by  the  Labelled  Security  Protection 
mechanism  (see  subsection  2.2.1)  of  the  TC8. 

The  main  changes  in  the  internal  logic  of  Unix 
required  to  support  file  systems  at  different 
levels,  that  are  combined  to  appear  as  one  com¬ 
posite  file  system,  has  been  limited  to  the 
namei  module.  In  standard  Unix,  it  is  the  namei 
module  that  performs  pathname  parsing  to 
retrieve  the  inode  that  represents  a  file. 

In  addition  to  the  enhancements  to  namei  that 
are  required  to  support  the  LOCK/ix  file  system, 
we  have  chosen  to  encapsulate  its  functionality 
in  a  file  server  subject  (see  subsection  4.3). 

4.2  File  System  Examples 

To  help  illustrate  how  the  files  system  will 
work  and  appear  to  users,  we  present  several 
simple  examples .  The  examples  are  built  on  the 
file  system  shown  in  Figure  7. 

Figure  a  shows  how  the  file  system  would  appear 
if  an  application  running  at  the  SECRET  level 
-eated  a  file  named  compute  in  the  directory 
usr/usex3.  Before  creating  the  file  compute, 
the  file  server  subject  was  required  to  create 
the  full  directory  path  at  the  SECRET  level  so 
that  the  file  could  be  placed  in  the  correct  the 
file  system, 

File  System  After  File  /usr/user3/compute 
Created  by  SECRET  Process 
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In  this  case,  only  the  path  component  /user3 
would  have  to  be  created  the  directory  /usr 
already  existed  at  the  SECRET  level.  The  inode 
numbers  for  directories  with  the  same  name  that 
exist  in  multiple  file  systems  can  be,  and  typi¬ 
cally  will  be,  different  in  each  file  system. 

The  application  running  at  the  SECRET  level  that 
created  the  file  compute  is  unaware  that  the 
directory  /user3  was  inherited.  There  will 
still  appear  to  be  only  one  /usr/user3  directory 
to  both  the  UNCLASS  and  SECRET  applications. 
However,  to  the  application  running  at  SECRET, 
/usr/user3  will  (potentially)  contain  more 
accessible  files  than  it  will  for  the  applica¬ 
tion  running  at  UNCLASS. 

If  a  file  named  /usr/user3/compute  already 
exiated  at  UNCLASS,  the  application  running  at 
SECRET  would  not  have  been  able  to  create  the 
file  since  a  file  of  that  name  would  have 
already  existed,  aa  a  read  only  file,  if  a  file 
named  /uar/user3/compute  existed  at  the  SECRET 
level,  the  process  running  at  UNCLASS  could 
still  create  the  file,  since  the  existence  of 
the  SECRET  /usr/user3/compute  would  not  be  known 
at  the  UNCLASS  level. 

Suppose  that  the  file  /usr/user3/compute  exists 
at  both  the  UNCLASS  and  SECRET  level.  An  appli¬ 
cation  running  at  SECRET  could  delete  the  file. 
The  file  /usr/user3/compute  at  UNCLASS  would 
remain  intact,  and  the  application  running  at 
UNCLASS  would  not  be  aware  of  the  fact  that  the 
(higher  level)  file  was  deleted. 

Figure  9  illustrates  the  file  aystem  after  the 
directory  /usr/user2/da  is  created  at  the 
UNCLASS  level,  and  the  file  display  is  created 
in  that  directory.  The  directory  /usr/user2/da 
exiated  at  the  SECRET  level.  However,  this  was 
not  know  not  at  the  UNCLASS  level  so  the  opera¬ 
tion  succeeds.  At  the  SECRET  level,  there  will 
still  appear  to  be  only  one  /usr/uBer2/da  direc¬ 
tory,  but  it  now  contains  the  file  display, 
which  is  read-only  to  processes  running  at  the 
SECRET  level. 

Figure  10  shows  the  results  of  the  removal  of 
the  directory  /usr/user3  by  a  process  running  at 
the  UNCLASS  level.  To  the  UNCLASS  process,  the 
directory  appeared  to  be  empty,  so  it  was  per¬ 
missible  to  unlink  (delete)  the  directory.  The 
directory  path  /usr/user3  at  the  SECRET  level  is 
left  undisturbed  by  this  operation. 

Maintaining  a  separate  file  system  per  level, 
and  providing  the  path  inheritance  capability 
allow  the  actions  described  in  the  examples  to 
be  performed  without  trusted  code.  Addition¬ 
ally,  since  file  systems  at  higher  levels  are 
not  known  to  processes  at  lower  level,  file  sys¬ 
tem  object  create  and  delete  operations  can  be 
performed  at  the  higher  levels  without  introduc¬ 
ing  covert  channels . 

4.3  Integrity  Considerations 

The  LOCK/ix  kernel  runs  in  the  same  virtual 
address  space  as  user  processes.  LOCK  does  not 
allow  a  single  subject  to  execute  in  multiple 
domains.  A  process  within  a  givon  LOCK/ix  sub¬ 
ject  could  gain  access  to  any  kernel  file  system 
structures  at  ita  level  and  modify  them.  It  is 
for  this  reason  the  file  system  update  opera¬ 
tions  are  removed  from  the  LOCK/ix  kernel  and 
implemented  in  separate  file  system  server  sub¬ 
ject  per  (active)  level.  Type  enforcement  is 
used  to  limit  write  access  to  critical  file  sys¬ 
tem  objects  (directories,  inodes,  etc.)  to  the 
file  server  subjects. 
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The  file  system  inode  table  is  broken  out  into 
two  parts:  non  critical  components,  such  as  time 
modified,  and  critical  components,  such  as 
object  UIDS.  The  non  critical  components  con¬ 
sist  of  fields  that  can  be  updated  by  the 
LOCK/ix  kernel  and  that  would  not  cause  any 
security  problems  if  they  were  updated 
incorrectly.  The  critical  components  will  be  in 
an  object  type  that  can  be  read  by,  but  not 
written  by,  the  LOCK/ix  kernel.  The  file  system 
server  subject  will  run  in  a  domain  that  is  dif¬ 
ferent  than  that  of  the  LOCK/ix  kernel  and  user 
processes,  and  will  hava  both  read  and  write 
eccess  to  the  critical  inode  table. 

The  file  aystam  server  will  only  perform  file 
system  update  operations;  it  will  not  run 
processes.  No  malicious  programs  that  could 
cause  unexpected  and  undesirable  consequences 
will  be  allowed  to  run  in  the  file  server 
domain.  This  particular  instance  shows  how  Type 
Enforcement  can  be  used  to  support  an  integrity 
policy  that  will  achieve  the  desired  end  result. 

5.0  Supporting  set-user- ID  Applications  on 
LOCK/ix. 

One  of  the  most  critical  factors  that  will  ulti¬ 
mately  decide  user  acceptance  of  a  secure  Unix 
system  is  whether  or  not  the  system  will  support 
set-usar-id/set -group-id  applications.  Our  work 
to  date  in  developing  the  model  for  LOCK/ix  has 
not  specifically  addressed  this  issue.  However, 
we  have  investigated  several  potential  models 
and  identified  one  that  appears  to  be  very 
promising  from  both  an  implementation  and  secu¬ 
rity  point  of  view.  We  call  this  the  new  sub¬ 
ject  model, 

To  support  this  model,  the  Unix  kernel  will  need 
to  be  modifiod  to  support  the  creation  and  start 
up  of  a  new  subject  that  will  contain  a  set- 
user-id  or  set-group-id  application.  For  sim¬ 
plicity,  we  will  discuss  this  process  in  terms 
of  set-user-id  applications  only,  set -group-id 
applications  would  be  handled  in  the  same 
manner . 

5.1  Create  New  Subject 

When  the  Unix  kernel  encounters  an  exec  0  system 
call,  it  determines  if  the  new  program  is  a 
set-user-id  application.  If  it  is,  it  makes 
sure  that  the  new  process  will  inherit  the 
parent's  environment  which  includes  things  such 
as  open  files.  In  LOCK/ix,  the  same  actions 
would  be  required.  However,  the  method  by  which 
the  new  process  inherits  thi3  environment  is 
somewhat  different  than  is  done  in  Unix. 

When  a  new  subject  in  LOCK  is  created,  it 
receives  what  is  called  a  new  subject  parameter 
object.  This  parameter  object  contains  all  the 
information  that  the  new  subject  will  need  to 
execute  in  its  environment.  The  format  and  con¬ 
tents  of  the  parameter  object  will  vary,  depend¬ 
ing  upon  the  application. 

When  a  new  subject  is  to  be  created  in  response 
to  an  execO  request,  the  LOCK/ix  kernel  will 
create  and  initialize  a  new  subject  parameter 
object  for  the  new  subject.  It  will  place  the 
following  information  in  the  parameter  object: 
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•  The  UID  of  the  set-user-id  application. 

•  The  UIDs  of  the  parent's  open  files. 

•  The  UID  and  process-id  of  the  parent  process. 


•  Environment  of  the  parent  process  (level, 
domain,  etc.) 

•  The  UID  of  a  signal  channel  of  the  parent 
process. 


This  information  will  provide  the  new  subject 
with  everything  it  needs  to  inherit  the  parents 
attributes,  and  establish  the  necessary  communi¬ 
cation  with  the  parent. 

The  LOCK/ix  kernel  will  then  ask  the  Ten  create 
a  new  subject,  specifying  the  UID  of  itself  as 
the  object  module  to  be  executed,  and  the  owner 
UID  of  the  set-user-id  application  as  the  user 
on  whose  behalf  the  new  subject  is  to  execute. 
This  will  have  the  desired  effect  (from  a  Unix 
point  of  view)  of  allowing  the  user  of  the  set- 
user-id  application  to  inherit  the  discretionary 
access  rights  of  the  owner  of  the  set-user-id 
application. 

5.2  Start  Up  of  the  New  Subject 

When  the  LOCK  TCB  allows  the  new  subject  to  exe¬ 
cute,  it  will  bogin  execution  in  tho  LOCK/ix 
kernel.  After  the  the  LOCK/ix  kernel  has 
created  and  initialized  its  data  structures,  it 
will  open  the  new  subject  parameter  object. 
Upon  opening  the  object  that  contains  the  set- 
user-id  application,  the  LOCK/ix  kernel  will 
discover  that  it  is  a  sot-user-id  application 
and  know  additional  processing  is  required  to 
start  the  new  process.  The  following  processing 
will  occur r: 


e  Open  the  text,  data,  and  stack  objects  for 
the  new  process. 

e  Open  the  files  of  the  parent  process. 

e  Retrieve  the  UID  and  process-id  of  the  parent 
process. 

a  Retrieve  the  environment  data  of  the  parent, 
e  Establish  a  signal  channel  with  the  parent. 


Theae  operations  are  essentially  what  is 
currently  done  in  Unix.  The  method  is  dif¬ 
ferent,  but  the  effect  is  the  same. 

As  stated  earlier,  our  current  model  of  LOCK/ix 
does  not  support  thi3  model.  To  support  it, 
there  are  two  primary  requirements  that  are 
placed  on  the  kernel: 


•  The  kernel  must  modified  »o  it  knows  that  it 
must  read  the  environment  information  out  of 
the  new  parameter  object  when  starting  a 
sat-user-id  application. 

e  The  Unix  signalling  mechanism  must  be 
enhanced  to  allow  inter-processing  signalling 
between  processes  contained  within  different 
subjects . 

The  first  requirement  ia  fairly  straight-forward 
to  implement .  The  things  that  must  be  done  to 
start  a  set-user-id  application  in  LOCK/ix  are 
not  much  different  than  what  is  currently  done 
in  standard  Unix. 

The  later  is  a  somewhat  mora  difficult  feature 
to  Implement  The  difficulty  in  implementation  is 
not  really  how  to  do  it,  but  how  to  do  it  in  a 
manner  that  is  compatible  (or  invisible)  at  the 
programmer  interface  to  the  kernel. 


Overall,  the  model  appears  to  be  promising  and 
will  be  investigated  further  in  the  future. 

6.0  Current  Status 

The  results  of  our  study  were  encouraging.  We 
were  surprised  to  find  how  much  of  the  Unix  ker¬ 
nel  code  can  be  retained  and  unmodified. 

A  continuation  of  the  design  began  in  April 
1988.  The  initial  implementation  of  LOCK/ix 
will  be  completed  by  April  1989.  This  version 
of  the  system  will  essentially  be  a  port  of  Unix 
to  LOCK. 

Upon  completion  of  the  initial  implementation, 

we  will  enter  an  enhancements  phase.  During 
this  phase  we  will  work  on  extending  the  func¬ 
tionality  to  incorporate  such  things  as  support 
for  set-user-id/set-group-id  applications.  We 
will  also  be  extending  the  standard  Unix  inter¬ 
face  to  incorporate  some  of  the  functionality 
provided  by  the  LOCK  TCB,  such  as  ACLs.  The 
enhancements  should  be  completed  by  July  1990. 
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1  Introduction. 

The  Department  oj  Defense  Trusted  Computer  System  Evaluation  Criteria 
(TCSEC)(4]  was  published  in  1083  to  establish  a  uniform  DoD  policy  for 
acquisition  of  trusted,  commercially  available,  automatic  data  processing 
systems.  The  agency  that  originally  produced  the  TC'SEC  is  now  called  the 
National  Computer  Security  Center  (NCSC).  It  was  established  to  assist  all 
sectors  of  the  Federal  government  in  acquiring  such  systems  by  evaluating 
prospective  trusted  systems  with  respect  to  the  Criteria  in  the  current 
version  of  the  TCSEC,  which  was  revised  and  re-published  as 
DOD  5200.2S-STD  (8], 

Since  the  publication  of  the  TCSEC,  the  NCSC  has  performed  two  major 
tasks  relative  to  evaluation  of  trusted  computer  systems.  It  has  evaluated  a 
number  of  commercially  available  operating  systems  and  added  entries 
describing  these  systems  to  the  Evaluated  Products  List  (EPL).  It  has  also 
published  interpretations  and  guidelines  intended  to  assist  its  evaluation 
staff,  tiro  vendors  of  trusted  eystems,  and  prospective  trusted  syetem  users. 

An  example  of  a  guideline  to  assist  the  vendor  is  A  Guide  to  Understanding 
Audit  in  Trusted  Systems  (3).  An  example  of  a  guideline  intended  to  assist 
the  uset  is  Cutdttiicr  /or  Applying  the  DoD  7 rusted  Computer  System 
Evaluation  Criteria  in  Specific  Environments  [2], 

The  formal  interpretation  process  has  resulted  in  publication  of  explanatory 
material  about  Individual  requirements  In  the  TCSEC.  The  moet  common 
type  of  interpretation  is  that  published  to  nnewer  a  question  concerning  how 
the  evaluation  staff  of  the  NCSC  intended  to  apply  the  TCSEC  to  a 
particular  technical  implementation.  Unlike  guideline#,  which  are  a  general 
explanation  of  the  TCSEC  requirement*  for  a  specific  audience,  an 
interpretation  is  an  authoritative  clarification  to  the  TCSEC,  and  has  lire 
same  authority  as  a  TCSEC  requirement.  By  nuking  an  Interpretation 
formal,  the  NCSC  evaluation  teams  can  apply  the  TCSEC  criteria  In  tho 
same  way  when  a  similar  Implementation  Is  encountered.  By  reading  the 
Interpretations,  vendors  are  able  to  avoid  designs  that  had  previously  caused 
problems  during  the  evaluation  process  and  to  tee  acceptable 
implementations.  As  an  outgrowth  of  the  Interpretation  process,  and  as  a 
result  of  vendor  requests  to  evaluate  products  that  do  not  exactly  fit  the 
mold  of  a  “trusted,  commercially  available,  automatic  data  processing 
system"  the  NCSC  has  published  the  Trusted  Network  Interpretation  (TNI) 
(6)  and  has  proposed  the  publication  of  "Computer  Security  Subsystem 
Interpretation  or  DoD  Trusted  Computer  Evaluation  Criteria"  (1). 

1.1  Purpose 

The  purpose  of  this  paper  I*  to  provide  guidance  to  those  who  must  certify 
that  a  proposed  computer  system  may  be  used  to  process  sensitive 
information.  In  the  military  realm,  this  is  a  Designated  Approving 
Authority;  in  the  civil  and  commercial  realm  there  are  equivalent  entities 
who  must  assure  proper  separation  of  data  (Vom  system  users.  Such 
separation  it  requited  by  law  or  best  business  practice.  Similar  guidance  is 
given  for  the  Department  of  Defense  In  [2],  which  provides  guidance  to  DoD 
personnel  concerning  which  level  of  TCSEC  protection  Is  required  for 
particular  mixtures  of  authorized  users  and  DoD  classified  or  sensitive  data. 
This  guidance  is  specific  to  entire  trusted  computer  systems,  and  done  not 
address  the  topic  of  trusted  subsystems  running  on  otherwise  untrusted 
computer  systems.  This  paper  will  provide  guidance  to  any  user  who  plans 
to  use  such  trusted  subsystems  by  pointing  out  how  sensitive  esch  such 
subsystem  it  to  other  parts  of  the  computer  system  in  which  it  is  installed. 
When  such  a  dependency  can  be  met  with  an  appropriate  evaluated 
subsystem,  then  it  will  be  recommended  that  the  dependent  evaluated 
subsystem,  and  the  evaluated  subsystem  on  which  it  depends,  both  be 
installed. 

It  is  not  the  purpose  of  this  paper  to  provide  a  guideline  on  the  use  of 
unevaluated  computer  eyetems  to  proceee  classified  information.  However,  if 
no  computer  system  on  the  Evaluated  Products  List  will  suffice  to  meet 
procurement  requirement*,  the  recommendation*  here  should  help  military, 
civil  and  commercial  procurement  personnel  in  choosing  »  viable  subset  of 
evaluated  protection  subsystems  to  install  on  their  system. 


1.2  Organisation 

In  addition  to  the  background  material  presented  in  this  suction,  the  paper 
contains  three  further  sections.  Section  2  provides  definitions  of  the  five 
types  of  subsystems  that  are  mentioned  in  the  proposed  Subsystem 
Interpretation  [1],  The  possible  subsystem  security  levels,  corresponding  to 
TCSEC  levels,  are  given  for  each  type  of  subsystem. 

Section  3  displays  a  dependency  graph  for  each  subsystem  level.  An 
explanation  is  given  for  each  arrow  of  the  graph.  Finally,  in  subsection  3.4  a 
chart  Is  used  to  show  all  recommended  secs  of  evaluated  euhsystums  that 
may  occur  for  at  least  one  level.  For  each  recommended  net,  the  most 
dependent  subsystem  within  that  set  has  all  the  subsystems  It  needs  to 
depend  on  also  included  in  the  set.  • 

2  Subsystem  Definitions 

Several  trusted  subsystems  have  already  been  added  to  the  Evaluated 
Products  List,  and  the  expertise  gained  during  those  evaluations  lias  keen 
used  to  propose  a  geucral  interpretation  of  the  TCSEC  to  the  task  of 
evaluating  subsystems.  In  particular,  it  has  described  which  types  of 
subsystem*  can  have  requirements  within  the  TCSEC  isolated  to  the  extent 
that  it  is  possible  to  evaluate  them  separately,  and  has  determined  what 
levels  of  trust  from  the  TCSEC  (Cl  through  Al)  may  be  applied  to  each 
such  subsystem.  The  evalustable  subsystems  arc: 

e  Discretionary  Access  Control  (DAC) 

a  Mandatory  Access  Control  (MAC) 

*  Object  Reus* 

*  Identification  and  Authentication  (MtA) 

*  Audit 

2.1  Details  of  Subsystem  Types 

In  the  following  sections,  each  type  of  subsystem  is  briefly  discussed,  and 
allowable  level  of  trust  values  given.  The  level  of  trust  values  are  from  the 
Subsystem  Interpretation,  and  correspond  to  the  equivalent  level*  of  truel  in 
the  TCSEC;  they  arc  designated  as  subsystem  levels  of  trust  by  preceding 
TCSEC  levels  with  S-.  For  example,  5-C2  in  the  Subsystem  Interpretation 
corresponds  to  C2  in  the  TCSEC. 

Discretionary  Access  Control  DAC  provides  usei-specified  access  control. 

This  control  is  established  from  security  policies  which  dcllnc,  given 
identified  subjects  ami  objects,  the  set  of  rules  that  are  used  for  the  system 
to  determine  whether  a  given  subject  can  be  permitted  to  gain  access  to  a 
specific  abject.  Tho  type  of  access,  such  as  read,  write,  append,  is  also 
determined  by  this  set  of  rules. 

To  be  evaluated  as  an  S-Cl  feature,  tile  DAC  subsystem  must  provide 
mediation  between  objects  and  syatem  u.  is.  For  S-C2,  the  mediation  must 
be  done  at  the  granularity  of  a  single  user,  end  objects  must,  as  the  default 
cose,  he  protected  from  the  time  of  their  creation. 

Mandatory  Acceea  Control  MAC  provides  access  control  for  classified  or 

other  specmcally  categorised  sensitive  information.  This  control  is 

established  from  security  policies  which  define  rules  for  controlling  and 

limiting  access  based  on  identifying  individuals  who  have  been  determined 

to  have  both  the  proper  authorisation  and  need-to-know  for  the  ., 

information.  A  MAC  subsyatem  may  be  evaluated  only  at  the  S-Bl  level,  ' 

corresponding  to  the  lowest  TCSEC  level  that  has  a  MAC  requirement.  , 

Ohjcct  Reuse  Object  rcuee  subsystem#  clear  storage  objeeti  to  prevent 

subjects  from  scavenging  data  from  storage  object*  which  have  previously  '< 

been  used,  Object  Reuse  subsystems  may  be  evaluated  only  at  the  S-C2  J 

level,  corresponding  to  the  lowest  TCSEC  level  with  this  requirement. 

Identification  end  Authentication  Ik  A  subiyetemi  provide  the  1 

Authenticated  identification  of  a  user  seeking  to  gain  access  to  the  protected  ) 

syetem.  The  most  typical  McA  system  consists  of  a  data  base  of  identifiers  i 

which  are  valid  on  the  system,  and  of  authentication  data  such  os  encrypted  i 

pauswordi.  However,  other  types  of  pertinent  physical  or  procedural  data 
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may  also  be  used  in  the  authentication  process.  Thi*  type  of  subsystem 
providee  feitile  ground  for  innovative  technological  aolutiona  to  one  of  the 
main  problema  of  secure  computing.  However,  in  order  to  meet  the 
appropriate  TCSEC  requirement,  the  computer  ayatem  itaelf  mutt  have 
accete  to  at  leaet  tome  partt  of  the  data  bate  ao  that  it  can  identify  the 
valid  ueera  of  the  ayatem. 

IlcA  aubayatema  may  be  evaluated  at  the  S-Cl  level,  or  at  S-C2  if  they 
provide  granularity  to  the  level  of  a  tingle  uaer.  If  the  aubayetem  it  able  to 
determine  the  clearance  and  allowable  authoriiatlon  levela  of  the  uaer,  then 
the  auhayatem  may  be  evaluated  at  the  S-Bl  level. 

Audit  The  audit  aubayetem  helpa  achieve  accountability  for  acceta  to  the 
ayatem  objeete  by  authorized  eubjecta  through  logging  data  from 
aecurity-relevant  eventa.  Thia  ailowa  a  ayatem  adminiatratsr  to  aearch  for 
poaalble  aecurity  breachea,  or  attempted  penetrationa,  and  to  trace  the 
breach  to  the  reapontible  party. 

TCSEC  levela  of  S-C2  and  S-Bl  are  potaible.  The  minimum  level  la  S-C2 
alnce  the  audit  log  data  mutt  Include  the  identity  of  the  peraon  for  whom  the 
aecurity  relevant  event  waa  attempted;  S-Bl  ia  poaalble  if  the  authoriiatlon 
level  of  the  individual  and  the  aecurity  level  of  the  object  are  both  recorded. 
An  additional  requirement  ia  that  event!  be  auditable  baaed  on  the  aecurity 
level  of  the  object.  In  the  event  that  all  eventn  are  logged,  one  muat  be  able 
to  generate  reporta  that  extract  only  eventa  involving  object!  at  the 
•pacified  aecurity.  The  final  S-Bl  requirement  ia  that  the  ayatem  be  able  to 
audit  attempt!  to  override  the  printing  of  human  readable  output  labela. 

2.2  Other  Requirementa 

In  addition  to  requirements  which  deacribe  specific  features  that  each 
subsyatem  muat  have,  the  Subayatem  Interpretation  impoaes  additional 
assurance  requirement!  and  documentation  requirementa  similar  to  those  in 
the  TCSEC.  These  requirements  are  in  the  arena  of  system  architecture, 
system  integrity,  security  testing,  design  specification  and  documentation, 
and  teat  documentation.  Furthermore,  a  description  of  how  to  use  the 
subsystem  In  a  secure  manner  must  be  Included  In  the  Security  Features 
User's  Guide  and  the  TVusted  Facility  Manual  that  must  accompany  any 
evaluated  lubsystoni. 


S  interdependence  of  Subsystems 

Inspection  of  the  various  features  and  assurance  requirement!  indicates 
that  secure  operation  of  certain  of  the  evaluated  subsystems  depends  on  the 
proper  working  of  other  subsystems.  The  draft  Subsystem  Interpretation 
does  not  specify  that  the  subsystem  tbs'  la  depended  on  must  also  have 

been  evaluated  under  the  Subsyr  . pretation  of  the  TCSEC.  However, 

It  only  seems  logical  to  make  sue.,  a  recommendation.  A  typical  example  of 
the  interdependence  of  evaluated  subeystems  occur*  with  the  audit 
subsyetem.  Thie  aubeystem  must  be  able  to  log  the  Identity  of  a  user  who 
causes  a  security  relevant  event  to  occur,  eo  an  I  A:  A  aubayetem  1j  required; 
however,  unlea*  the  IfcA  subsystem  haa  been  evaluated  and  found  to  meet 
the  TCSEC  criteria,  it  Is  possible  that  tne  lit  A  subsystem  can  be  spoofed 
causing  the  audit  ayatem  to  record  the  wrong  username  in  it*  log  record. 

Alao,  since  the  TCSEC  may  Impoae  an  additional  requirement  at  each 
increasing  level  for  each  requirement  section,  so  the  evaluated  subsystems 
should  only  depend  on  other  subsystems  that  have  met  their  additional 
requirements.  For  example,  an  S-C2  audit  subsystem  ehould  not  depend  on 
an  S-Cl  IlcA  subsystem  since  it  is  possible  for  lie  A  to  bn  evaluated  at  S-C2. 

The  intent  of  this  paper  is  to  provide  recommendations  as  to  which 
combinations  of  evaluated  eubiyatema  will  nature  that  the  most  dependent 
subsystem  in  each  combination  it  relying  only  on  appropriately  evaluated 
subsystems.  Thia  effort  ia  made  in  the  same  spirit  aa  the  Guidance  tor 
Apply inj  fAe  TCSEC  in  Sptcifie  Environment)  [2].  In  the  section!  that 
follow,  for  each  criteria  level  a  dependency  tree  will  be  derived  allowing 
which  aubayatema  are  dependent  on  which  other  aubayatnma. 


Figure  1:  Sample  Dependency  Tree 


This  paper  will  derive  a  dependency  graph  for  each  eubayatem  level  of  trust. 
In  tuch  a  tree,  an  arrow  from  a  aubayatem  to  another  aubaystem  means  that 
the  flrat  aubayatem  relie*  on  the  correct  functioning  of  the  aecond  subayatem 
for  its  own  correct  functioning.  All  recommended  combinations  of 
aubayatema  may  then  be  derived  by  hating  for  each  subayatem  in  each  graph 
all  the  aubsyatema  in  the  subgraph  for  which  it  ia  the  root.  Thua,  the 
notation  example  in  figure  1  illustrate!  the  notation  that  it  uaed  in  this 
paper  to  show  that  subayatem  SUBa  depends  for  its  correct  working  on 
subsystem  SUBb  alao  working  correctly.  So  the  two  recommended 
combinations  are  {SUBb}  and  {SUBa,  SUBb).  Note  that  {SUBa}  ia  not 
recommended  since  it  depend!  on  an  evaluated  subsystem  SUBb  for  its 
correct  functioning. 

Exceptional  caws  may  exist  where  all  subsystems  in  a  dependency  aubgraph 
are  not  to  be  evaluated.  The  official  certifying  a  computer  ayttem  for  the 
proceaaing  of  senaitive  data  muat  decide  whether  to  follow  the 
recommendations  in  this  paper  or  to  entruat  the  senaitive  data  to  a  partially 
secured  system.  Thia  ia  alwaye  the  case,  since  the  EPL  ia  only  one  input  to 
the  certification  process.  This  paper  ia  an  attempt  to  provide  guidance  on 
the  truslcdnese  of  systems  that  are  secured  only  by  the  addition  of 
evaluated  eubiyatema. 

Before  getting  to  the  recommendations  and  their  rationale,  it  is  worth 
noting  that  an  object  reute  subsystem  does  not  have  any  dependence  on  any 
other  of  the  four  typea  of  aubsyatemn  described  in  the  Subsystem 
Interpretation,  and  will  not  be  discussed  further. 

3,1  S-Cl  Level 

At  the  S'Cl  level,  iho  following  graph  in  Figure  2  can  be  derived. 


Figure  2:  Dependency  Graph  at  S-Cl 
which  yields  the  seta  (UcA),  {DAC.l&A}. 

Tile  DAC  mechanism  must  decide  whether  an  authorized  user  or  user  group 
may  accssi  a  particular  subject.  The  11c A  mechanism  at  this  level  has 
granted  the  user  access  to  the  system  and  has  at  least  Identified  chat  user  aa 
a  member  of  a  particular  group.  The  DAC  mechanism  requires  t  ie 
knowledge  of  which  group  of  users  the  particular  user  belongs  to  in  order  to 
make  the  access  control  decision.  A  non-evaluated  IlcA  system  might  allow 
a  user  to  login  as  another  user,  without  authorisation,  or  to  masquerade  as 
the  membit  of  any  group  and  thus  gain  access  to  any  object. 

Jl.l  -S.-.C2,  Lsvtl 

At  the  S-C2  level,  the  dependencies  shown  in  Figure  3  can  be  derived; 


Figun  3:  Dependency  Graph  at  S-C2 

which  yields  the  seta  {IlcA},  {DAC.I&A},  {Audit, IlcA},  and 
{Audit, DAC, l&A}. 

DAC  depends  on  IlcA  for  the  same  reasons  aa  those  previously  discussed  for 
S-Cl,  only  more  ao  since  the  11:A  ayatem  must  identify  the  subject  down  to 
the  granularity  of  a  single  uaer, 

If  there  ia  a  DAC  subsystem  present,  Audit  depends  on  it  for  two  reasons. 
The  first  reason  derives  from  the  fact  that  most  aecurity  relevant  events  at 
the  C2  level  are  due  to  attempted  access  to  objects  by  identified  subjects. 
To  depend  on  a  non-evaluated  DAC  subsystem  to  report  all  such  events 
accurately  would  mean  that  the  audit  system  waa  not  getting  information 
that  ia  accurate  at  the  C2  level  since  the  non-evaluated  DAC  subsystem  may 
not  fulfill  all  the  TCSEC  requirements.  The  second  reason  is  the  implicit 
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requirement  to  protect  the  audit  log  data  with  the  beet  resources  available 
to  the  computer  system.  If  an  S-C2  DAC  system  exists  on  the  system,  the 
audit  log  data  should  be  stored  in  an  object  which  is  restricted  by  DAC  to 
the  appropriate  access  by  a  limited  set  of  administrative  personnel. 
Alternatively,  the  system  could  protect  iis  audit  logs  in  an  appropriately 
configured  Write  Once  Head  Many  (WORM).  This  could  be  used  even  if  an 
evaluated  DAC  subsystem  were  present.  Such  devices  already  exist  ill  the 
form  of  writalde  optical  disks.  The  optical  disks  must  be  unloaded  and 
processed  on  a  separate  audit  machine. 


At  the  S-Dl  level,  the  dependency  graph  111  Figure  4  can  be  derived: 


Figured:  Dependency  Graph  at  S-Ul 

This  yields  the  recommend'  <cis  (li’.A),  (l& A.MAC),  (IA. A, DAC, MAC], 

{ Audit, MACiIStA),  and  {Ah  iiuDAC.MAC.IAA). 

S-111  MAC  depends  on  S-B!  !A:A  to  obtain  the  clearance  and  allowed  range 
of  authorization  levels  when  the  user  logs  in.  S-C2  DAC  depends  on  at  least 
an  S-C2  1AA  system,  but  in  all  S-111  system  it  would  depend  on  an  S-Bl 
MtA  because  It  is  required  for  MAC  and  lias  already  met  all  Hie  S-C2 
requirements  on  the  way  to  fulfilling  the  S-Ul  requirements. 

If  the  S-C2  DAC  subsystem  is  present,  then  it  must  depend  on  the  MAC 
subsystem  to  provide  the  separation  of  subjects  and  objects  according  to 
authorisation  levels  and  necd*to-know  categories.  Thou  the  DAC  subsystem 
provides  discretionary  access  to  objects  within  each  level  and  category. 
Although  the  TCSEC  [5]  requires  any  11  level  or  higher  system  to  have  both 
DAC  and  MAC.  there  is  no  requirement  in  the  Subsystem  Interpretation 
dial  both  exist.  A  bl  level  system  requires  MAC  to  enforce  the 
nwd-to-kliow  and  authorization  requirement.  The  S-IU  l&A  system  is  still 
needed  by  the  Audit  subsystem  since  it  is  required  to  record  the 
authorization  of  a  user  when  the  Audit  subsystem  togs  a  security  relevant 
event.  Similarly,  the  S-BI  level  audit  system  is  required  since  it  must  record 
the  label  of  any  object  and  the  authorization  of  any  subject  involved  iu  any 
security  relevant  event.  This  is  lint  a  requirement  at  S-C2, 

The  Audit  subsystem  must  depend  on  MAC  to  protect  the  audit  logs  ill  a 
S-Dl  system  since  the  logs  themselves  mny  contain  classified  information, 
such  as  the  names  of  categories.  The  most  effective  way  to  do  tills  is  to 
create  a  system  high  sensitivity  level  and  a  special  category  just  for  the 
audit  logs.  As  with  S-C2  DAC,  the  audit  subsystem  depends  on  the  DAC 
subsystem,  if  present,  and  the  MAC  subsystem  to  truly  report  all  security 
rclevunt  events  which  a  lion-evaluated  access  control  subsystem  might  not 
report  correctly.  It  also  needs  the  MAC  system  to  truly  report  the 
sensitivity  level  of  each  object  Involved  in  a  report  of  a  security  relevant 
event.  The  audit  subsystem  depends  on  an  S-111  hie  A  system  to  provide  it 
the  clearance  and  authorization  level  of  each  user  which  it  needs  to  report  in 
the  audit  log. 

3.4  Summary 


The  information  in  the  above  dependency  graphs  can  be  summarized  in 
Table  1.  which  appears  without  Hie  levels  of  trust  from  the  Subsystem 
Interpretation.  The  chart  was  compiled  by  aggregating  all  recommended 
sets  of  subsystems  that  appeared  for  each  of  the  levels  in  the  previous 
section.  These  are  listed  in  the  "Recommended  Combinations"  aids  of  the 
chart.  Ail  other  combinations  of  evaluated  subnyetema,  whether  they 
depend  on  an  unevsluated  subsystem  or  are  some  kind  of  standalone 
system,  are  not  recommended  for  use  in  a  trusted  computer  system  to 
process  sensitive  data.  Also,  the  Subsystem  Interpretation  warns  that  the 
subsystem  rating  is  no  guarantee  that  the  system  into  which  the  evaluated 
subsystem  is  integrated  then  becomes  equivalent  to  a  similarly  rated 
integrated  system,  such  as  the  systems  that  are  evaluated  against  the  entire 
TCSEC.  This  paper  points  out  that  even  evaluated  subsystems  may  have 
their  value  in  the  security  of  an  overall  system  overstated  if  they  are  allowed 
to  rely  on  other  unevaluated  subsystems. 


Table  1:  Possible  Combinations  of  Evaluated  Subsystems 


RECOMMENDED 

Tot  AeCom  mended 

UiA 

l&A,  audit 

UiA,  DAC 

UtA,  DAC.  audit 

UiA,  MAC 

I&A,  DAC,  MAC 
l&A,  MAC,  audit 

I&A,  DAC,  MAC,  audit 

ruxe - 

MAC 

audit 

MAC',  audit 

DAC,  audit 

DAC,  MAC 

DAC,  MAC,  audit 
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ABSTRACT 

This  paper  will  present  three  classes  oi  authentication  mechanisms  in  use 
today.  In  addition,  it  will  also  show  the  need  to  change  the  Trusted 
computer  system  Evaluation  Criteria  (TCSEC)  at.  its  upper  levels  such  that 
new  means  of  authentication  will  be  encouraged  in  the  next  generation  of 
products  evaluated  by  the  National  Computer  Security  Center. 


HISTORY 

Background 

on  January  2,  1981,  the  Oireotor  of 
the  National  Security  Agency  was 
assigned  the  responsibility  for 
increasing  the  use  of  trusted 
computer  security  produots  within 
the  Department  of  Defense.  As  a 
result,  the  PoD  Computer  Security 
Center  was  established  at  the 
National  Seaurity  Agency.  Its 
official  charter  is  contained  in  Don 
Directive  5215.1.  The  Center  became 
known  as  the  National  Computer 
security  Center  (NCSC)  in  August 
1985. 

The  primary  goal  of  the  NCSC  is  to 
enaourage  the  widespread 
availability  of  trusted  computer 
systems/  that  is,  systems  that 
employ  sufficient  hardware  and 
software  integrity  measures  for  use 
in  the  simultaneous  processing  of  a 
range  of  sensitive  or  classified 
information.  Such  encouragement  is 
brought  about  by  evaluating  the 
technical  protection  capabilities  of 
industry-  and  government-developed 
systems,  advising  system  developers 
and  managers  of.  their  systems' 
suitability  for  use  in  processing 
sensitive  Information,  and  assisting 
in  the  incorporation  of  computer 
security  requirements  in  the  systems 
acquisition  procass. 

Illfi  NCSC  Computer  Security  sub¬ 
system  Evaluation  Ecagmn 

while  '-.he  NCSC  devotes  muoh  of  Its 
resouraes  to  encouraging  the 
production  and  use  of  large-scale, 
multi-purpose  trusted  computer 
systems,  there  is  a  recognized  need 


for  guidance  on,  and  evaluation  of, 
computer  security  produots  that  do 
not  meet  all  of  the  feature, 
architecture,  or  assurance 
requirements  of  any  one  security 
□lass  or  level  of  the  TCSEC.  The 
NCSC  has,  therefore,  established  a 
Computer  Security  Sub-system 
Evaluation  Program. 

The  goal  of  the  NCSC's  Computer 
Security  Sub-system  Evaluation 
Program  is  to  provide  computer 
installation  managers  with 
information  on  sub-systems  that 
would  be  helpful  in  providing 
immediate  computer  security 
improvements  to  existing 
installations. 

Sub-systems  considered  in  the 
program  are  special-purpose 
products  that  can  be  added  to 
existing  computer  systems  to 
increase  some  aspect  of  security 
and  have  the  potential  of  meeting 
the  needs  of  both  civilian  and 
government  departments  and 
agencies,  For  the  most  part,  the 
scope  of  a  computer  security 
sub-system  evaluation  is  limited  to 
consideration  of  the  sub-system 
itself,  and  does  not  address  or 
attempt.  to  rate  the  overall 
security  of  the  processing 
environment.  To  promote 
consistency  in  evaluations  an 
attempt  is  made,  where  appropriate, 
to  assess  a  sub-system's 
security-relevant  performance  in 
light  of  applicable  standards  and 
features  outlined  in  the  TCSEC. 
Additionally,  the  evaluation  team 
reviews  the  vendor's  claim-  and 
documentation  for  obvious  flaws 
which  would  violate  the  product's 
security  features,  and  verifies, 
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through  functional  tasting,  that  the 
product  performs  as  advertised . 
Upon  completion,  a  summary  of  the 
evaluation  report  is  placed  on  the 
Evaluated  Products  List. 

Many  of  the  sub-systems  evaluated  in 
this  program  have  been 
Identification  and  Authentication 
sub-systems.  These  systems, 
although  deemed  useful,  do  not  tend 
to  be  incorporated  in  larger  TCSEC 
evaluated  systems  because  they  would 
constitute  a  change  to  the  Trusted 
Computing  Base  (TOB) .  Such  a  change 
to  any  evaluated  system  renders  the 
rating  assigned  void.  Although  the 
weakest  Identification  and 
Authentication  mechanism,  a  password 
mechanism  is  currently  acceptable 
for  all  levels  of  the  TCSEC. 
Because  of  this  and  the  added  cost 
of  incorporating  another  type  of  ISA 
mechanism,  vendors  currently  in  or 
considering  evaluation  by  the  NCSC 
for  a  TCseo  rating  have  chosen  not 
to  incorporate  other  I&A  mechanisms. 


INTRODUCTION 

The  Department  sX  B&Iqms  Iraafc&d 
computer  system  Evaluation  Criteria 
is  built  around  three  basic  control 
objectives,  the  security  policy, 
accountability,  and  assurance  [1]. 
Much  emphasis  is  placed  on  better 
meeting  the  security  policy  and 
assurance  objectives,  while 
accountability  is  often  taken  for 
granted.  In  fact,  the  requirements 
stated  in  the  TCSEC  are  more 
centered  around  security  policy 
(Mandatory  and  Discretionary  Aaooss 
Controls)  and  assurance 
(Documentation  and  Verification) 
than  accountability  (Identification, 
Authentication,  and  Audit) .  New 
technologies  are  being  developed 
which  will  better  meet  this 
requirement  and  the  computer 
security  community  needs  to  take  a 
look  at  them,  encouraging  their  use 
where  appropriate. 

Briefly,  Identification  and 
Authentication  (I&A)  is  the  process 
by  which  users  log  onto  a  computer 
system.  The  identification  step 
simply  identifies  who  the  user  is, 
by  account  name.  Authentication  is 
the  step  which  proves  that  the  user 
(person)  is  indeed  the  owner  of  that 
account.  As  these  are  so  closely 
associated,  usually  they're 
considered  as  tha  same  thing.  In 
reality,  idantification  is  easily 
implemented  while  authentication 
needs  more  consideration. 

The  importance  of  this  issue  can  be 
demonstrated  by  citing  the 


Department  of  Defense  Trusted 
Computer  System  Evaluation 
Criteria's  Control  Objectives  [1]: 

Identification  is 
functionally  dependent  on 
authentication.  Without 
authentication,  user 
identification  has  no 
credibility.  Without  a 
credible  identity,  neither 
mandatory  nor  discretionary 
security  policies  can  be 
properly  invoked  because 
there  is  no  assurance  that 
proper  authorizations  can  be 
made. 

The  conclusion  from  the  above 
paragraph  is  that  the  credibility 
of  any  security  policy  is  directly 
dependent  on  the  credibility  of  the 
authentication  mechanism  backing 
it. 

The  strength  of  an  I&A  mechanism 
can  be  measured  in  terms  of  the 
certainty  that  the  person 
requesting  access  is  indeed  who  he 
claims  to  be.  Quantifying  this 
certainty  is  difficult,  however,  a 
feel  for  the  relative  strength  can 
be  gained.  For  example,  if  the 
authentication  of  a  user  could  be 
duplicated  by  any  user,  the 
mechanism  would  have  certainty  of 
0%.  While  a  method  which  would 
distinguish  between  every  possible 
person  in  ths  world  would  have  a 
certainty  of  100%.  Since  the 
latter  does  not  exist,  something 
which  closely  approximates  it  is 
the  most  desirable  mechanism. 

There  are  several  areas  which  have 
been  recognized  as  legitimate  tests 
of  user  uniqueness.  These  are 
things  that  the  user  knows,  things 
which  the  user  has,  and  things  that 
the  user  is.  While  there  is  no 
quantitative  way  to  measure  the 
certainty  of  any  of  these,  the 
strengths  and  weaknesses  of  each 
area  can  be  examined  and  compared 
to  each  other. 


THINGS  you  KNOW 

avecYiw 

The  objects  which  ars  categorized 
as  being  "things  you  know"  includes 
passwords  and  all  password  like 
mechanisms  (such  as  pass-phrases). 
A  password  is  known  by  the  user  and 
only  the  user.  virtually  anyone 
who  has  ever  used  a  computer  system 
is  familiar  with  the  concept  of 
passwords  as  being  special  words 
which  must  be  entered  before  access 
tc  the  computer  is  allowed. 
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Passwords  work  on  principle  of 
being  a  secret  between  the  computer 
and  the  user.  The  computer  can 
only  be  sura  of  the  user's  identity 
if  they  know  the  same  secret.  The 
better  this  secret  is  kept,  the 
better  the  password  scheme. 

Strengths 

The  strength  of  a  password  scheme  is 
very  dependent  on  its 
implementation.  Passwords  become 
stronger  as  difficulty  in  forging 
them  increases.  The  Department  of 
Defense  Password  Management 
Guideline  (CSC-STD-002-85)  [2] 
provides  specific  guidance  on  how  to 
make  a  strong  password  system. 

Passwords  guessing  should  be  like 
hitting  a  moving  target.  Good 
schemes  allow  the  userc  to  change 
their  passwords  and  require  it  be 
done  on  a  regular  basis. 

Machine  generated  passwords  ars  also 
important.  This  reduces  the  biases 
(such  as  the  user's  first  or  last 
name,  wife 's/husband's  name,  pet's 
name,  ad  infinitum)  which  are 
present  in  user  chosen  paeswords , 
resulting  in  a  much  better  mix. 
This  results  in  a  much  larger  set  of 
targets  which  must  be  examined. 


The  strengthening  of  passwords  on 
any  system  tends  to  have 
consequences  which  at  the  same  time 
weakens  some  of  the  basic  principles 
of  passwords. 

Making  passwords  more  difficult  to 
guess  also  makes  them  harder  to 
remember.  This  increases  the  chance 
that  a  less  than  cautious  or  well 
informed  user  will  write  them  down. 
In  a  large  computing  environment 
this  becomes  very  likely.  Also, 
this  is  likely  to  happen  if  the  user 
is  only  logged  onto  a  system 
occasionally. 

If  passwords  are  difficult  to 
remember,  as  machine  generated 
passwords  can  be,  they  tend  to  get 
changed  less  often  by  the  users. 
Users  are  just  not  willing  to  learn 
a  new  jumble  of  letters  every  few 
days.  This  causes  the  target  to 
move  less  frequently.  If  the  system 
has  a  password  expiration 
capability,  e>  system  security 
administrator  is  be  able  to  foroe 
users  to  change  their  passwords  more 
frequently,  but  this  increases  the 
likelihood  that  the  passwords  will 
be  written. 


Passwords  on  a  network  make  for 
interesting  security  problems . 
Imagine  a  user  who  has  accounts  on 
30  nodes  of  a  network.  If  able  to 
choose  his  own  password,  the  user 
will  most  likely  use  the  same 
password  on  each  node  for  ease  of 
use.  If  this  is  the  case,  hacking 
the  password  on  one  node 
compromises  each  node  the  user  has 
access  to.  On  the  other  hand,  if 
password  generation  in  enforced  on 
eaah  node  of  the  network,  it  is 
likely  that  the  user  will  have 
scripts  containing  the  node  and 
password  because  it  is  simply  too 
difficult  to  remember  30 
"pronounceable"  passwords. 

The  most  serious  weakness  is  that 
compromise  of  passwords  is  not 
usually  detected  until  well  after 
any  damage  has  taken  place.  Even 
when  users  regularly  check  the  time 
that  they  last  logged  in,  it  may  be 
several  days  between  sessions  by 
the  legitimate  user  of  the  system. 
This  is  more  than  enough  time  for 
the  damage  to  be  dona . 

There  are  a  number  of  other  similar 
methods  which  have  been  thought  up 
which  are  inherently  weak.  Instead 
of  passwords,  users  are  asked  a 
series  of  questions  about  their 
background,  typically  their 
mother's  maiden  name,  first  car,  or 
their  pet's  name.  These  methods 
fail  basic  password  philosophies  in 
that  while  this  information  is  not 
common  knowledge,  it  is  far  from 
being  secret. 


THINGS  YOU  HAVE 

aYfir.yJ.sw 

Those  things  that  fall  under  the 
category  "Things  You  Have"  can  be 
thought  of  as  Identifiers  similar 
to  badges  worn  for  entrance  to 
buildings.  Ownership  of  the  badge 
authenticates  that  person  as 
belonging  to  a  particular  company 
or  holding  a  particular  position. 

Likewise,  things  that  fall  under 
this  category  are  physical  devices 
that  provide  authentication  via 
possession  of  the  device.  Such 
devices  include,  but  are  not 
limited  to:  smart  cards,  tokens, 
data  keys,  encryption/decryption 
keys,  magnetic  strip  cards, 
calculator-type  devices,  random 
number  generators,  laser  cards, 
code  decryptors,  and  the  like. 
These  devices  are  normally 
incorporated  into  systems  through 
the  use  of  special  dedicated 
hardware  and  software.  They  can 
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include  front-end  or  back-end 
processors,  vendor-written  machine 
speaific  software,  and 
buyer-written  machine  specific 
software.  Depending  on  the  amount 
of  storage  available,  these  devioes 
may  also  contain  audit  data, 
biographic  data,  and  account 
balances. 

Most  devices  in  this  category  also 
incorporate  mechanisms  that  fall 
under  the  other  two  categories 
covered  in  this  paper.  Take,  for 
example,  a  money  machine  card. 
Although  one  needs  this  card  to 
acoess  the  machine,  one  must  also 
know  the  Personal  Identification 
Number  associated  with  that  card  in 
order  to  conduct  business  at  any 
automatic  teller  machine.  This 
example  incorporates  a  mechanism 
from  the  "Things  you  Know"  category. 
Likewise,  with  a  credit  card,  one 
must  physically  posses  the  card  to 
bo  able  to  transact  business,  but 
one  must  also  be  ablet  to  forgo  the 
signature  on  the  aard.  This  example 
incorporates  a  mechanism  from  the 
"Things  You  Are"  category. 

To  use  a  specific  example  of  such  a 
device,  Sytek's  PFX  A2Q0Q  [6]  has 
been  chosen.  This  device  has  been 
evaluated  by  the  National  Computer 
Security  Center  Sub-system 
evaluation  program.  The  PFX  A2000 
system  contains  a  back-end  processor 
that  interacts  with  the  host  machine 
through  the  use  of  buyer-written 
machine  specific  software.  From  the 
users  perspective,  a  typical  login 
scenario  would  be  the  following. 

The  user  begins  by  entering  his 
login  identifier  to  the  host  system. 
The  host  system  passes  this 
information  to  the  back-end 
processor  which  returns  a 
challenge/response  combination.  The 
host  displays  the  challenge 
information  on  the  user's  terminal 
and  prompts  the  user  for  a  response. 
The  user  enters  his  PIN  into  a 
calculator-type  device,  followed  by 
the  challenge  displayed  on  the 
terminal  screen.  The  calculator 
processes  this  number  to  produce  the 
correct  response  which  the  user  then 
enters  to  the  host  machine,  thus 
granting  him  access. 

Siisnatha 

Manufacturers  have  been  placing  a 
great  deal  of  emphasis  on  the 
usefulness  of  "Things  You  Have"  in 
the  areas  of  Identification  and 
Authentication.  Since  they  are 
portable  devices,  they  can  be 
carried  by  the  user  and  used  to 
replace  or  enhance  password  systems 
which  ere  commonly  used  today.  Data 


about  the  holder  can  be  stored  on 
the  device  such  that  either  the 
device  passes  data  to  the  host 
system  to  be  used  in  querying  the 
user  or  the  device  queries  the 
user.  Vendors  Btate  that  it  is 
nearly  impossible  for  a  person, 
after  acquiring  another's  device, 
to  unlock  the  memory  stored  there. 
This  is  mainly  due  to  the  use  of 
Personal  Identification  Numbers  to 
authenticate  the  user  to  the  device 
and  custom  built  chips  which 
require  the  destruction  or  the  chip 
to  glean  any  useful  information. 

Another  advantage  to  having  a 
device  for  an  authentication 
mechanism  is  that  it  is  easy  to 
determine  when  a  compromise  may 
have  occurred.  A  user  may  only 
logon  to  the  system  if  he  possesses 
the  device.  The  loss  of  the  device 
would  oertainly  signal  that 
compromise  may  have  occurred. 

If  each  system  in  a  network  uses 
the  same  type  of  device  for 
authentication,  a  user  would  only 
need  the  one  device  to  access  each 
node  of  the  network.  Thus,  a  user 
would  not  be  required  to  remember  a 
different  password  for  each  node  or 
use  the  same  password  for  each 
node,  A  device  that  changes  with 
each  login  attempt,  such  as  a 
random  number  generator  or 
challenge/response  device, 
strengthens  the  schema  even  more. 

Weaknesses 

A1X  things  categorized  under 
"Things  You  Have"  have  thn  same 
basic  weakness  du«  to  their  main 
strength:  they  are  physical  devices 
and  are  thus  subject  to  physical 
protection  issues.  Possession  of  a 
card  implies  that  the  user  is  who 
he  says  he  is.  The  host  system,  in 
effect,  is  authorizing  the  device 
rather  than  the  user. 

Although  a  device  is  useless  as  an 
authenticator  without  the  proper 
identifier,  many  of  the  devices  now 
marketed  have  the  associated 
identifier  embossed  on  them.  They 
a.  so  tend  to  be  carried  with  other 
personal  possessions,  such  as  in  a 
wallet,  where  the  identifier  can 
often  be  quickly  surmised. 

With  the  proper  technology,  these 
devices  can  be  easily  forged.  For 
example,  if  the  device  is  simply  a 
smart  card  with  a  number  contained 
on  it,  anyone  that  can  write  to  a 
similar  smart  card  can  gain  access 
to  the  system.  Depending  on  the 
level  of  technology  involved,  this 
may  be  a  trivial  task,  thus 
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providing  no  authentication 
assurance  whatsoever. 

Lastly,  although  these  devices  are 
lees  expensive  than  their  biometric 
counterparts,  they  tend  to  be  more 
expensive  than  the  development  of 
password  mechanisms  and  are 
therefore  not  very  cost  effective 
in  the  development  of  general 
purpose  machines. 


THINGS  YOU  ARE 

Overview 

In  recent  years  a  new  type  of 
authentication  mechanism  that  works 
based  on  some  characteristic  of  a 
user  has  appeared  in  the 
marketplace.  Devices  which  use 
this  type  of  authentication 
mechanism  are  known  as  biometric 
devices.  Biometria  devices  work  by 
attempting  to  matoh  some  unique 
characteristic  of  a  user  with  a 
known  version  of  the 
characteristic.  Common 
characteristics  currently  being 
used  include  fingerprints,  eye 
retina  patterns,  voice 
characteristics,  and  signatures. 
For  biometria  devices  to  work  as  an 
effective  authentication  mechanism 
in  an  ADP  environment,  the  known 
version  of  the  characteristic  must 
be  protected  from  modification  by 
users  of  the  system.  This  requires 
that  the  known  version  be  treated  as 
an  object  that  is  protected  by  the 
TCB. 

One  example  of  a  biometric  device  is 
the  IDX-50  from  Identix 
Incorporated.  The  IDX-50  has  been 
evaluated  by  the  NCSC  sub-system 
evaluation  program  [3],  The  IDX-50 
provides  authentication  data  to  a 
host  based  on  a  comparison  between  a 
user's  fingerprint  and  a  pattern 
(representing  the  user's 
fingerprint)  stored  on  a  smart  card. 
The  result  of  the  comparison  made 
(either  confirmed  or  denied)  is  sent 
to  ths  host  systsm. 

Strengths 

Unlike  other  authentication 
mechanisms,  biometrics  makes  it 
almost  impossible  for  a  user  to  pass 
his  means  of  authentication  to 
another  user.  For  example,  a  user 
can  tell  someone  his  password  or 
give  someone  his  smart  card,  but 
giving  someone  his  fingerprint  in  a 
form  that  will  be  accepted  is 
extremely  difficult.  By  linking  a 
characteristic  of  the  user  to  the 
authentication  process,  biometrics 
eliminates  the  possibility  that  the 


user's  means  of  authenticating 
himself  to  the  system  ie  easily 
obtained  by  another  user. 

One  of  the  most  important  features 
of  an  authentication  mechanism  is 
how  difficult  it  is  to  spoof. 
Biometria  authenticators  are 
extremely  difficult  tc  spoof 
because  of  the  complexity  that  most 
biological  characteristics  have. 

We&Knessgg 

Biometric  devices  use  some  unique 
characteristic  of  a  user  as  an 
authentication  data  point. 
Unfortunately,  it  is  impossible  for 
the  user  to  present  the 
characteristic  in  the  exact  same 
form  as  the  known  version.  For 
example,  a  finger  may  have  more  oil 
on  it  on  a  particular  day  than  that 
which  was  on  it  at  the  time  the 
known  version  was  obtained.  This 
could  cause  the  newly  soanned  image 
to  vary  slightly.  To  account  for 
the  variations  it  is  neoessary  to 
allow  some  tolerance  when  comparing 
the  authentication  data  point  to 
the  known  version.  The  larger  the 
tolerance,  the  greater  the 
likelihood  that  bad  data  will  be 
accepted  (Type  I  errors) .  In 
contrast,  ths  smaller  the 
tolerance,  the  greater  the  chance 
that  good  data  will  not  be 
accepted  (Type  IX  errors) , 

There  is  a  yet  unexplored  ethical 
side  to  biometrics  concerning  user 
acceptance.  Cats  and  other  animals 
can  mark  and  identify  territories 
by  urine  traces  around  the 
perimeter.  Suppose  someone  devises 
a  method  of  performing  foolproof 
authentication  via  a  device  that 
performs  instant  urinalysis.  Each 
terminal  could  be  equipped  with  one 
of  these  devices  and  a  sign 
reading:  "For  login,  please  deposit 
sample  here."  Likewise,  a  device 
able  to  perform  a  spectrcgraphic 
analysis  where  the  user  must  supply 
his  own  blood  sample  would  probably 
have  a  fairly  serious  user 
acceptance  problems  [9],  Case 
studies  of  users  concerning 
fingerprint  readers  and  retinal  eye 
scanners  have  shown  that  users  are 
greatly  reluctant  to  use  these 
devices.  Very  few  people  are 
willing  to  place  their  finger  in  a 
hole  in  the  aide  of  their  terminal 
as  an  authentication  mechanism  for 
foar  of  bodily  harm.  Many  people 
ere  also  reluctant  to  have  their 
fingerprint/eyeprint  stored  on 
line. 

Although  the  coot  of  biometric 
devices  has  been  steadily 


337 


decreasing,  they  are  still  the  most 
costly  of  the  authentication 
mechanisms  available.  The  unit 
price  of  these  products  can  vary 
from  about  $3500  to  $10000  £8]. 
Prices  of  this  nature  make  them  too 
costly  for  many  general  purpose 
applications. 


CONCLUSIONS 

The  TCSEC  requires  that  the  TCB 
obtain  some  data  that  will 
authenticate  a  user  before  granting 
access  to  system  resources. 
Authentication  data  falls  into 
three  general  categories: 

1)  Something  the  user  knows. 

2)  Something  the  user  has. 

3)  Something  the  user  is. 

"Something  the  user  knows"  is  some 
piece  of  knowledge  which  a  user 
must  memorize  and  present  to  the 
TCB  at  authentication  time.  A 
password  is  an  example  of  this  type 
of  authentication  data.  "Something 
the  user  has"  is  a  physical  device 
which  a  user  must  present  to  the 
TCB  at  authentication  time.  A 
smart  card  is  an  example  of  this 
type  of  authentication  data, 
"something  the  user  is"  is  a 
characteristic  that  a  user  must 
present  to  the  TCB  at  authentication 
time.  A  fingerprint  is  an  example 
of  this  type  of  authentication  data. 

The  TCSEC  does  not  require  that  more 
than  one  type  of  authentication  data 
be  presented  to  the  TCB.  In  fact, 
all  computer  systems  that  have  been 
evaluated  by  the  HCSC  at  this  time 
have  used  password  based  mechanisms 
(i.e.  mechanisms  based  on 
"something  the  user  knows") .  If  an 
evaluated  product  were  to  change  its 
authentication  mechanism  such  that 
two  or  more  pieces  of  authentication 
data  were  required  before  granting 
access  to  system  resources  (thereby 
strengthening  the  mechanism)  the 
rating  would  be  invalidated  due  to  a 
change  of  the  TCB. 

As  has  been  shown,  each  type  of 
authentication  data  discussed  in 
this  paper  has  some  weaknesses 
however,  these  weaknesses  seldom 
overlap.  Therefore,  a  combination 
of  these  mechanisms  would  most 
likely  bo  a  stronger  authentication 
mechanism.  One  mechanisms  strengths 
could  compensate  for  another 
mechanisms  weaknesses.  Since  the 
TCSEC  defines  what  is  minimally 
acceptable  at  a  given  level  of 
trust,  it  should  be  modified  at  its 


upper  levels  to  require  that 
developers  of  trusted  ADP  systems 
require  at  least  two  types  of 
authentication  data 

(Have/Know/Are)  before  gaining 
aooess  to  system  resources. 
Current  technology  has  created 
other  mechanisms,  that  can  be  used 
to  strengthen  authentication  than 
were  readily  available  at  the  time 
the  TCSEC  was  written.  The  HCSC 
should  encourage  the  use  of  these 
mechanisms. 
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Most  people  who  attend  conferences  are 
Immersed  for  a  certain  length  of  time  in  a  subject 
they  are  interested  In.  They  share  ideas,  develop 
new  ones,  Improve  their  people  networks,  and 
occasionally  have  a  good  time  besides.  When 
they  go  back  to  work  they  will  be  "pumped"  and 
some,  especially  those  who  are  relative  new¬ 
comers  to  the  business,  will  be  ready  to  help  out 
all  their  office  companions  by  giving  them  new¬ 
found  wisdom  and  maybe  even  "changing  a  few 
things"  to  make  them  work  better,  Tney  are 
frequently  discouraged  and  somewhat 
disappointed  by  the  responses  they  will  most 
often  get.  People  are  not  ready  to  respond  and 
may  even  be  downright  negative.  Having  a 
conference  about  security  will  not  make  this  any 
easier  for  two  reasons.  First,  security  is  not 
one  of  the  favorite  topics  of  most  office 

Eersonnel,  unless  they  happen  to  work  in  the 
usiness  all  the  time.  Second,  changing 
people’s  attitudes  towards  a  subject  doesn't 
happen  quickly;  it  happens  a  little  bit  at  a 
time,  over  a  long  period  of  time  (1].  This  is 
what  makes  security  so  interesting  and  so 
difficult. 

What  security  awareness  does  is  sell 
security  procedures  and  performance  consistent 
with  those  procedures,  in  the  computer 
environment,  security  means  restraint  on  an 
activity  that  is  far  more  efficient  unrestrained, 
so  some  people  are  not  Just  going  to  refuse  to  buy 
it,  but  will  challenge  the  right  to  sell  it  at  all.  A 
small  minority  of  people  will  actively  fight  a 
security  program;  a  small  minority  will  actively 
support  it  [21:  the  rest  of  the  population  is  the 
principle  target  audience  for  a  security  awareness 
program. 


The  measure  of  success  is  how  many  people 
follow  the  procedures  they  are  trained  to  follow. 
Knowing  how  many  don't  Is  a  matter  of  auditing 
and  testing  of  the  system,  something  that 
reinforces  whatever  education  and  training 
preceded  It.  It  is  always  best  to  train  first,  test 
second,  or  there  is  little  way  to  measure  the 
success  of  the  training.  To  get  performance  one 
must  train  to  a  standard  ana  measure  the 
performance.  Some  people  honestly  believe  that 
education  atone  will  result  in  action,  when  they 
should  realise  that  it  won't.  If  advertising 
campaigns  worked  with  the  same  logic,  the  goal 
would  be  to  get  the  audience  to  know  a  trade 
name,  but  not  really  care  if  anyone  bought  the 
product.  To  be  effective,  they  have  to  do  both. 

Awareness  is  not  easy,  but  it  is  easier  than 
getting  performance.  To  be  effective  it  must 
follow  principles  of  organisational  and 
Interpersonal  communication.  The  first  is  that 
people  don't  always  get  messages  that  are 
directed  to  them  [31.  As  a  trainer,  I  have 
occasionally  been  reminded  of  this  when  students 
ask  questions  about  subjects  that  have  just  been 
covered  in  class.  It  shouldn't  be  surprising. 
Nobody  ever  sold  anything  without  overcoming 
this  problem. 

People  are  "tuned"  to  different  types  of 
media  to  get  the  majority  of  their  information 
from  particular  types;  some  are  print  oriented; 
some  are  video  oriented;  some  may  be  oriented  to 
things  they  listen  to  [4],  in  order  to  sell  products, 
advertisers  use  a  variety  of  media  over  a  length  of 
time  so  that  sometimes  it  seems,  unless  a  person 
is  near  death,  they  will  get  the  message.  Stiff, 
they  don't  always  get  it  or  perform  by  buying  the 
product. 


Program  Changes  Attitudes  Towards  Security 


What  a  security  awareness  program  does  la 
change  people's  attitudes  towards  security 
procedures  and  policy.  The  selling  aspect  of 
advertising  recognises  much  of  what  a  security 
person  needs  to  know  about  attitude  change. 

While  there  is  a  large  body  of  research 
surrounding  the  activity  and  an  equally  large 
amount  of  money  being  spent  on  it,  its  success  is 
seldom  measured  in  terms  of  days  or  weeks  and  is 
far  from  guaranteed,  The  best  minds  in  the 
business  fail  as  often,  sometimes  more  often, 
than  they  succeed.  Pew  people  in  security 
education  like  to  admit  it,  but  they  don't  do 
much  better.  One  obvious  problem  they  have  is  a 
measure  of  success  to  check  performance  against. 
Unlike  advertising  where  there  is  a  market 
feedback  for  the  successful,  security  seems  to 
have  no  such  product  to  measure. 


.  «<*«*  to  assure  a  person  gets  the  message, 

advertising  has  to  be  memorable  -  good  or  bad. 
Mediocre  A  death.  We  are  so  bombarded  by 
media  that  we  don't  have  rime  for  average 
commercials  and  the  same  goes  for  security. 
Many  active  programs  fall  because  they  are 

iood  uot  bad.  Bad  is  not  recommended, 
but  it  is  more  memorable  than  mediocre.  Overall 
»“ve  to  *PPe«  in  a  variety  of  media 
over  an  extended  period  of  time  and  most  of 
those  have  to  be  good,  i.e.  interesting  enough  to 
read,  or  Heard.  Usually  this  also  meant 

short* 

An  audience  has  an  attention  span  of  about 
20  minutes,  a  long  time  when  compared  to  a 

P11®*  Wfcjftt  we  have  many  people  who 
t*rink  it  is  a  great  idea  to  get  everyone  together 
and  do  all  the  security  training  at  once.  A  mid- 
western  contractor  used  to  do  this  once  a  year  for 
B  hours,  meeting  every  required  security  briefing 
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for  all  of  lta  employees;  it  looks  good  on  paper 
and  is  well  documented,  but  It  doesn’t  work.  In 
the  same  way,  some  people  write  long  articles  for 
house  organs  or  publications  and  believe  these 
are  read  by  large  numbers  of  people.  Long 
articles  about  security  are  only  read  by  security 
people,  and  not  very  many  of  those.  Some  people 
make  monumental,  epic  films  which  are 
occasionally  viewed  by  somebody,  but  not  often 
remembered  by  very  many.  Steven  Spielberg 
makes  memorable  films,  but  if  everyone  could  do 
this,  they  wouldn't  pay  him  nearly  as  well  for 
what  he  does. 

Posters  are  the  best  illustration  of  a  print 
media  that  gives  a  short  message.  Posters  are  for 
people  who  haven’t  the  time  to  read  very  much 
about  security.  A  popular  misconception  is  that 
this  means  people  who  are  undereducated  or  low 
on  intelligence.  Along  the  mahogany  rows  are 
just  as  many  people  who  are  overwhelmed  by  the 
amount  of  text  coming  across  their  desks.  They 
don't  read  well  either,  when  it  come  to  security. 

In  order  to  be  noticed  posters,  like 
advertising,  have  to  be  good  or  bad.  The  federal 
government  has  frequently  made  a  series  of 
mediocre  posters  which  are  not  memorable. 
Lockheed  Space  and  Missile  Co.  in  Sunnyvale,  CA 
has  made  many  of  the  best :  A  teddy  bear  with 
badge  around  its  neck  and  the  inscription  "We 
can't  bear  it,  if  you  don't  wear  It";  three  otters 
standing  side  by  side,  with  the  inscription  "You 
otter  not  talk  classified  when  you"re  out  with  the 
gang";  and  a  series  of  cave  dwelling  comic 
characters  representing  computer  security  items 
of  concern  and  containing  the  telephone  number 
of  the  computer  security  office.  They  are  done  by 
commercial  artists  and  well  thought  out.  They 
have  to  lock  these  up  or  they  are  regularly  stolen 
by  employees  and  visitors. 

Crude  drawings  can  be  just  as  effective.  A 
quick  (and  cheap)  source  of  these  is  a  local  grade 
school.  Children  are  perceptive  and 
uncomplicated  In  the  way  they  express  their 
ideas,  though  not  always  artistic.  The  art 
sometimes  falls  into  the  "bad"  category  of 
advertising,  but  is  frequently  memorable.  It  also 
helps,  as  I  saw  Sheraton  Hotels  do  once,  to  put 
the  originators  name  on  the  bottom  along  with  a 
ribbon.  Everyone  had  a  red  or  blue  ribbon  with 
absolutely  no  legend  to  explain  what  these  meant. 
Parents  intently  looked  at  them,  at  least  until 
they  found  the  one  they  were  looking  for,  but 
they  get  the  message  represented. 

There  are  many  media  to  ehoose  from  and 
not  enough  activities  make  use  of  all  of  them. 
Audio  tape,  in  the  land  of  the  Walkman,  could  be 
an  effective  media  for  foreign  travel  or  special 
access  briefings,  changes  in  operating  procedures 
and  certain  training  where  the  user  has  the 
equipment  In  front  of  them.  Video  cameras  make 
it  possible  for  anyone  to  demonstrate  how  to  do 
various  tasks,  including  something  as  simple  as 
logon  procedures.  Interactive  video  does  this 
better,  but  it  Is  much  more  expensive  to  develop. 
Off-line  computer  aided  training  can  be  done  In 
house  relatively  Inexpensively.  Various  forms  of 
print  from  job  aids  to  comic  books  will  work.  The 
trick  Is  to  not  try  to  do  everything  with  any 
single  media.  Break  it  up  into  small  pieces  and 
use  several  forms  to  get  the  message  across. 

Don't  be  afraid  to  repeat  points  from  one  aspect 
to  another. 


Honing  a  Message  to  Present 


Perhaps  a  harder  task  than  selecting  a 
medium  is  selecting  the  message  to  be  put  across. 
The  government  makes  this  somewhat  easier  by 
having  certain  required  subjects  that  have  to  be 
covered.  DODSI  deals  with  the  protection  of 
classified  information,  both  In  and  out  of 
computers,  but  the  guidance  is  applicable  to  any 
environment  where  Information  is  to  be 
protected. 

Everyone  in  government,  and  in  Industry 
where  classified  work  Is  done,  has  to  have  an 
initial  security  briefing  outlining: 

1)  The  Importance  of  the 
Information 

2)  The  obligation  of  every  person 
to  protect  it 

3)  Procedures  which  govern  the 
protection 

4)  Reporting  requirements  for  certain 
status  changes  (e.g.  foreign  travel, 
establishing  relationships  with 

ersons  from  designated  countries, 
ankruptcy  and  the  like) 

5)  Laws  and  rtatutes  governing 
espionage 

Initial  briefings  should  be  short  because  a 
new  employee  is  not  very  receptive  to  much  of 
anything  except  their  boss  and  payroll 
procedures.  Tne  acknowledgment  of  the  briefing 
can,  however,  be  very  important,  particularly 
where  there  are  obligations  for  protecting  trade 
secrets,  process  patents,  and  other  proprietary 
information.  Borland  and  Microsoft  recently  went 
to  court  over  a  similar  business.  The  point  here 
la  that  the  employee  know  that  some  types  of 
information  will  be  safeguarded  and  there  are 
procedures  to  tell  them  how  this  Is  to  be  done. 

Of  course,  there  has  to  be  a  corporate  policy  and 
procedures  or  this  type  of  briefing  will  be 
ceremonial. 

Actual  briefings  on  procedures  should 
be  In  work  centers.  Rarely  are  these  done,  or 
done  well  when  they  are.  Work  center  briefings 
are  more  current  and  credible  than  any  other  an 
employees  will  receive.  They  will  actually  use 
this  information  often  and  should  be  geared  to 
training  i.e.  performance.  It  has  to  be  more  than 
"Here  is  your  password."  Work  center  briefings  in 
classified  information  settings  cover  very 
generally  these  types  of  things: 

1.  Where  classified  Is  stored  and  how 
access  Is  to  be  gained  to  it 

2.  How  it  Is  made  available  to  the 
employee 

3.  How  it  is  to  be  protected  while  in 
use 

4.  What  unauthorised  acts  are 
reportable 

8.  What  actions  to  take  if  an 
unauthorized  act  is  observed 
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6.  Machine  specific  (AIS)  procedure! 
are  to  be  followed: 

a.  upgrading  a  system  to  process 

b.  in  use  controls  of  media, 
hardcopy,  and  visuals 

c.  marking  output  products 

d.  when  to  downgrade  or  declassify 
a  system 

e.  audit  trail  records  activity 

f.  emergency  procedures 

7.  Internal  labeling 

8.  How  access  is  governed  during 
processing 

0.  Who  Is  to  be  escorted  and  escort 
responsibilities 


The  media  used  to  present  these  Ideas 
should  vary  depending  upon  the  length.  Some  of 
these  can  be  done  with  CAE  since  computers  can 
best  duplicate  the  environment  the  employee  will 
operate  In.  Others  can  be  written  and  used  when 
the  task  has  to  be  performed.  Unfortunately  this 
Is  not  always  any  better  than  some  software 
documentation  and  has  to  be  done  as  well  as  the 
best  of  It.  Some  of  it  Is  a  one-on-one  supervisors 
briefing,  and  some  can  be  written  summaries  of 
laws  and  regulations,  covering  computers  in  the 
work  place.  A  combination  Is  more  effective  than 
a  single  medium. 

The  government  also  requires  security 
deficiency  Briefings  which  are  statements  to 
employees  of  conditions  Identified  during 
Inspections  or  internal  audits.  This  is  just  a  good 
business  practice,  but  it  Is  not  always  done.  In 
order  to  get  across  to  other  employees,  the 
problems  of  a  few  doesn't  mean  that  problems 
have  to  be  stated  exactly,  by  naming  names, 
times,  and  dates.  A  general  overview  would  be 
adequate  through  a  memo,  a  short  Internal  house 
organ  article,  or  a  letter  to  supervisors.  Nothing 
irritates  Inspectors  or  auditors  more  than 
identifying  a  type  of  problem  In  one  shop  or 
building  and  having  It  come  up  again  somewhere 
else  during  the  next  audit. 


Perhaps  the  most  difficult  area  of  briefings 
are  those  that  require  action  by  the  employee  to 
report  suspicious  behavior  or  actions  of  another 
employee.  The  government  places  considerable 
emphasis  on  the  Individual  In  a  managerial  or 
supervisory  position  to  report  factors  which  may 

Influence  a  person's  position  of  trust.  Similar 
security  procedures  are  frequently  stated  or 
implied  In  other  requirements  outside  of  the 
government.  People  see  Indicators  that  can 
signal  Internal  abuses  and  fraud,  the  most 
difficult  kind  to  detect.  Getting  them  to  report 
these  may  require  more  than  a  written  or  verbal 
statement  that  it  should  be  done.  For  several 
reasons  employees  don't  want  to  "rat"  on  their 
friends  or  cowcrkers.  For  one  thing,  there  is  the 
matter  of  reciprocity,  l.e.  if  I  tell  on  you,  you  may 
tell  on  me.  For  another,  Willis  Ware  of  RAND 
pointed  out  several  years  ago  that  it  would  be 
possible  to  stop  computer  crime  by  planting 
Informants  In  every  DP  shop,  only  the 


consequences  would  not  be  worth  achieving  the 
result.  Balance  Is  really  the  goal.  Gossip  has  to  be 
discouraged,  but  the  tendency  is  to  do  otherwise. 
Security  people  tend  to  think  that  lots  of 
Information,  however  incredible  it  may  be,  is 
better  than  very  little.  A  little  quality 
information  about  certain  auditable  activities  is 
far  more  beneficial  than  a  hundred  rumors  that 
will  create  more  dissentton,  mistrust,  and 
internal  squabbling  than  they  are  worth. 
Management  has  to  agree  on  what  is  going  to  be 
said  »out  a  policy  and  how  such  reports  are  to  be 
investigated. 


Making  a  Security  Program  Visible 


In  many  ways  security  will  not  survive 
without  management  support.  No  organization 
can  have  more  security  than  management  wants 
or  will  tolerate.  Management  is  also,  then,  a 
target  audience  for  security  awareness.  I  have 
seen  a  few  Security  Officers  do  this  well.  They 
never  miss  a  chance  to  keep  security  in  the 
management  mind.  Particularly  in  computer 
security,  this  means  keeping  them  Informed  on 
incidents  Inside  and  outside  of  the  company, 
something  that  can  be  done  with  newspaper  and 
periodical  summaries  of  computer  crimes  and 
abuses,  and  memos.  It  means  Including  them  In 
the  general  security  awareness  program  on  other 
Issues  and  soliciting  their  support  on  policy, 
discipline,  and  money  for  the  security  program. 
Another  recommendation  is  to  be  personally 
Involved  with  top  level  management.  If  they  are 
new  to  the  organization,  go  over  security 
procedures  with  them  one-on-one.  Be  well 
prepared  and  brief,  but  cover  the  essentials. 

Leave  a  telephone  number  In  case  they  have 
difficulties  and  handle  their  Inquiries  personally. 
If  an  audit  shows  some  problem  they  are  having, 
help  correct  it.  and  keep  notes  on  what  was  done. 
Visit  now  and  again  and  show  the  flag. 

There  Is  another  time  to  keep  accurate 
notes  when  dealing  with  management.  Some 
security  officers  think  that  their  role  is 
tantamount  to  a  mission  from  God  and  their 
approach  to  management  parallels  this.  It  is 
possible  to  treat  every  security  incident  as  the 
only  one  there  has  ever  been  and  the  worst  there 
ever  will  be.  Every  policy  decision  can  be  a  life  or 
death  struggle.  A  dispute  over  money  can  be 
another  Persian  Gulf  crisis.  This  doesn't  mean 
that  a  security  person  has  to  be  meek,  but  there 
is  a  limit  to  pushing  a  point.  A  security  officer  is 
responsible  for  doing  three  things: 


1.  Make  management  aware  of  Its 
responsibilities 


2.  Advise  on  the  realistic  consequences 
of  not  meeting  those  responsibilities 


3.  CYA,  a  short  term  which  translates  into 
Take  Good  Notes 


341 


Personally  dealing  with  management  carries 
an  aspect  of  being  visible  to  the  public  of  the 
work  place.  Security  people  who  bottle 
themselves  up  in  an  office  with  a  terminal  and 
100  different  reference  books,  put  a  large  sign 
outside  that  says  Computer  Security,  and 
announce  to  all  that  they  are  "available"  anytime, 
rarely  are.  I  used  to  go  around  with  security 
people  who  had  to  introduce  themselves  to 
everybody  we  met.  Part  of  security  awareness  is 
being  out  where  the  people  are  answering 
questions,  and  finding  out  what's  going  on,  Most 
of  our  security  audiences  are  very  uncomfortable 
sitting  for  a  week  In  a  class  because  they  are  used 
to  being  out  of  their  offices.  They  should  be. 

The  danger  in  being  out  where  oeople  are  is 
that  they  ask  questions  that  are  difficult  to 
answer.  This  sometimes  means  saying,  "I  don't 
know,  but  I'll  find  out."  Finding  out  means  both 
people  learned  something  and  the  nest  time  the 
same  question  comes  up,  the  answer  is  ready. 

This  Is  what  makes  experts.  People  move 
hardware  all  the  time,  add  equipment,  change 
offices,  move  walls,  build  buildings  and  a  host  of 
other  things  that  affect  security.  They  don't 
always  call  and  tell  the  one  responsible  that  it  Is 
being  done.  This  is  sometimes  called  "liaison" 
with  personnel,  maintenance,  engineering, 
physical/ administrative  security,  the  DP  staff 
itself,  and  a  few  others.  It  is  just  a  specialized 
form  of  security  awareness.  Making  people  who 
are  the  "changers”  aware  that  what  they 'do  may 
affect  what  we  do.  They  will  usually  "make 
conversation"  if  you  come  around  in  areas  that 
are  of  security  Interest.  It  always  helps  to  keep  a 
security  program  proactive  instead  of  reactive; 
remembering  that  security  is  more  than  Just 
paper  and  audit  records,  will  help  to  do  that. 

While  a  security  person  Is  out  and  about,  there 
are  two  special  kinds  of  people  to  look  for.  The 
first  is  that  small,  but  important  group,  who  will 
do  their  security  functions  well,  in  spite  of  often 
getting  nothing  for  it  and,  rarely  if  ever,  having 
any  mention  of  security  in  their  job  description. 
Security  people,  as  a  group,  are  the  most 
persecuted,  downtrodden,  neglected,  and 
underpaid  people  in  the  world,  at  least  to  hear 
them  talk.  On  the  underpaid  part,  they  are  right. 
A  DP  staff  will  not  be  very  sympathetic  because 
they  also  fit  Into  the  same  category.  This  is  all 
the  more  reason  to  go  out  and  find  the  people 
who  are  doing  a  good  job  and  say  "thank  you" 
once  in  awhile.  Every  one  of  these  people  does  a 
job  that  the  security  person  would  have  to  do  if 
they  didn't.  They  deserve  some  thanks  for  this, 
and  it  will  be  rewarding  for  both  parties. 

The  other  kind  of  person  lies  at  the  other 
extreme  of  the  cooperation  spectrum.  This  is  the 
kind  of  person  who  won't  cooperate,  hasn't  got 
time  for  security  measures,  and  doesn't  like 
anyone  coming  around  telling  them  how  to  act. 
This  person  needs  help  --  a  special!  ted  kind  of 
security  awareness.  The  type  of  approach  is  one 
that  comes  from  The  Godfather  ;  make  them  an 
offer  they  can't  refuse.  Reason  with  them  in  a 
way  they  cun  understand.  This  doesn't  mean 
threaten,  or  even  give  the  appearance  of  doing  it. 
Tone  and  inflection  have  quite  a  bit  to  do  with 
how  a  message  is  perceived  [6j.  Start  with  the 
policy  of  the  agency  or  company  e.g.  this  real 
policy  of  a  large  defense  contractor: 


The  first  violation  results  in  a  letter 
being  placed  in  the  person's  personnel 
file.  This  assumes  the  action  was 
Inadvertent  or  accidental. 

The  second  violation  results  in  a  5  day 
suspension  without  pay.  This  may 
occur  for  a  willful  or  intentional 
violation  even  If  it  is  the  first 
occurrence. 

The  third  violation  results  in 
dismissal, 


There  Is  no  threat  made  or  implied  in  the 
expression  of  the  policy.  This  is  help  for  a  person 
who  would  otherwise  be  surprised  by  the  action. 
Apologizing  for  the  policy  or  the  action  is  equally 
poor  procedure.  The  person  needs  the  facts  in  as 
straight-forward  a  manner  as  possible.  Every 
good  security  person  knows  who  the  people  are 
who  need  this  kind  of  attention.  It  is  partially  an 
instinct,  and  partially  being  visible  to  the  various 
audiences  the  security  person  must  serve. 


Media,  Messages,  and  the  Program  Objective 


Any  person  who  has  a  security  responsibility 
has  an  obligation  to  inform  and  educate  the 
audiences  they  serve.  When  they  get  together,  at 
a  conference,  a  symposium,  or  at  a  chapter 
meeting  of  a  security  group  in  their  area,  they 
learn  things  they  want  to  do  when  they  get  back. 
Usually,  they  try  to  do  too  much,  too  fast. 

Security  education  doesn't  work  quickly,  even 
when  spurred  on  by  a  management  generated 
crises.  It  has  to  work  slowly  and  in  small, 
"chcwable"  pieces.  Map  out  what  is  to  be  done 
and  make  a  list  of  priorities.  Divide  the  list  into 
obtainable  objectives  and  select  media  of  several 
types  to  carry  the  messages  to  the  target 
audiences.  Keep  the  same  messages  going  out.  on 
a  regular  basU  to  get  them  to  people  who  missed 
them  the  first  and  second  time  or  arc  new  to  your 
activity. 

Second,  test  to  see  that  the  education  results 
in  performance.  The  same  office  may  not  be 
responsible  for  education  and  testing  so  the 
education  program  has  to  mesh  with  the  testing 
objectives.  Coordinate  the  education  program 
with  auditors  and  inspectors  to  see  that  It  meets 
their  program  direction.  Ask  for,  and  expect, 
feedback  that  will  support  or  change  the  thrust  of 
the  security  education  effort  end  give  feedback 
where  H  works  (people  get  the  message!  but 
doesn't  result  in  performance.  This  may  be  a 
function  of  poor,  or  unenforceable  policy  that 
needs  to  be  changed. 

Third,  get  out  of  the  office  and  actually  do  the 
Job.  Reinforce  the  good  and  mitigate  the  poor 
performance  where  ever  possible. 

Security  awareness  Is  more  than  a  program;  it 
is  a  way  of  doing  the  things  that  make  up  a 
security  officer's  responsibilities.  It  doesn't  come 
quickly  or  easily  and  deserves  the  same  amount 
o?  attention  that  other  aspects  of  the  security 
program  receive.  It  means  prevention  more  than 
correction,  though  some  of  each  is  required.  It 
requires  planning,  coordination,  and  a  lot  of  hard 
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work  to  implement.  In  the  end,  it  means  making 
the  security  person’s  job  easier  by  having 
employees  perform  at  an  acceptable  level,  not 
because  someone  tells  them  they  have  to,  but 
because  everybody  else  does  it  too. 
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Abstract 

This  paper  discusses  the  concept  of  a  software  analysis 
procedure  to  aid  in  the  conversion  of  existing  applications 
and  in  the  development  of  new  applications  for  use  with  a 
Trusted  Computing  Base.  The  use  of  this  analysis  within 
two  separate  projects,  one  involving  conversion  of  existing 
software  and  one  involving  development  of  new  software, 
is  discussed  to  demonstrate  the  process  and  to  provide 
background  for  our  conclusions. 

Introduction 

Recent  developments  in  the  field  of  computer  security 
have  brought  about  a  great  need  for  provable  secure 
systems  that  operate  in  accordance  with  DoD  6200.29- 
STD,  known  as  the  Orange  Book,  published  by  the 
National  Computer  Security  Center  I NCSC)  fit.  With  the 
emergence  of  several  trusted  computing  bases  (TCBs)  in 
the  last  year,  meeting  the  goal  of  fielding  secure  systems 
has  become  a  possibility.  There  is  also  significant  effort  on 
the  part  of  several  vendors  to  develop  B  level  generic 
networks  and  data  base  management  systems  (DBMSs). 
This  leaves  a  neglected  area  in  secure  systems  -- 
integration  of  the  "rescue"  of  the  investment  in  an 
installed  software  base  when  secure  systems  are 
implemented.  Eor  these  reasons,  Grumman  Data  Systems 
(GDS)  has  developed  a  manual  software  analysis 
procedure  designed  to  aid  in  the  conversion  of  unlrusLed 
applications  software  for  use  with  a  generic  TCB. 

Software  Analysis 

The  software  analysis  consists  of  a,  step-by-step  process  to 
determine  which  pieces  of  the  application  software  need  to 
be  trusted  and  which  do  not.  Figure  I  gives  a  graphic  view 
of  this  process. 


FlGUtlE  I.  SOFTWARE  ANALYSIS 


The  first  step  is  to  break  the  software  down  into  modules 
(routines  and/or  subroutines)  and  then  identify  which 
modules  perform  a  security-related  function.  Security- 
related  implies  that  the  module  function  relates  to 
enforcement  of  the  security  policy  and/or  accountability 
criteria  detailed  in  the  Orange  Book  [1).  These  modules 
must  be  part  of  the  trusted  soltware. 

Modules  identified  with  security-related  functions  must 
then  be  further  analyzed.  Because  of  the  burden  of  proof 
placed  on  trusted  software  during  certification,  the  use  of 
new  trusted  software  must  be  minimized,  Any  of  these 
security-related  functions  which  will  now  be  supplied  by 
the  TCB  can  be  eliminated  from  the  applications  at  this 
point.  All  remaining  security-related  modules  must  be 
further  analyzed  and  broken  down  into  the  smallest 
entities  possible  until  they  eventually  consist  of  only  those 
functions  that  absolutely  must  be  trusted.  When  these 
software  entities  have  been  reduced  to  the  absolute 
minimum,  they  are  then  further  analyzed  to  eliminate 
any  duplicate  functions. 

These  minimum  security-related  entities  are  then  isolated 
as  trusted  processes  under  the  control  of  the  TCB.  This 
isolation  requires  well  structured  software  with  a  clearly 
defined  and  strictly  enforced  TCB  interface,  If  the 
software  is  not  well  structured,  the  requirements  should 
be  reviewed,  the  software  redesigned,  and  then  analyzed 
again. 

The  next  step  is  to  correlate  all  routines  that  do  not 
contain  any  security  relevancy  and  all  software  entities 
that  do  not  need  to  be  trusted;  these  form  the  bulk  of  the 
untrusted  software  of  the  system  and  should  be 
restructured  and  integrated  together, 

Converting  Existing  Applications 

Initially,  CDS  developed  this  project  to  explore  the 
possibility  of  applying  retrofitting  procedures  to 
applications  running  on  an  untrusted  multilevel  system. 
We  assumed  that  a  TCB  would  soon  be  available  to  rehost 
existing  applications,  and  we  targeted  on  determining 
what  would  be  necessary  to  convert  existing  applications 
for  use  with  that  TCB. 

'The  untrusted  multilevel  system  in  use  performs  basic  C3I 
functions.  Data  is  entered  into  the  system  from  either  an 
external  communications  system  or  manually  from  a 
single  keyboard.  After  entry  and  labeling,  the  data  is 
transformed  into  internal  format  and  maintained  in  the 
DBMS  where  it  can  be  manipulated  by  the  user  on  site. 
The  system  also  produces  intelligence  data  to  be  output  to 
various  offsite  users.  The  security  clearances  of  the  off¬ 
site  users  were  used  to  determine  the  protection  levels 
required  for  internally  generated  data.  The  current 
system  uses  three  protection  levels;  high  (Top  Secret  with 
compartments),  medium  high  (U.S.  Secret),  and  medium 
(Secret  Releasable). 

Two  alternative  system  designs,  multilayered  (kernel 
based  [2])  and  multilevel  (totally  trusted  12)),  were 
originally  considered  to  offer  the  best  solutions  to 
converting  this  system  to  a  trusted  multilevel  capability. 
We  considered  only  these  two  architectures  because  our 
research  showed  that  that  only  these  approaches  are 
likely  to  reach  the  higher  (B3-A1)  certification  levels. |2| 
Each  design  requires  a  TCB  hut  the  multilevel  approach 
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also  requires  a  trusted  DBMS  and  trusted  applications. 
We  chose  the  multilayered  approach  because  of  our 
interest  in  utilizing  our  existing  application  base  and 
because  no  trusted  DBMS  exists. 

The  multilayered  approach  uses  existing  (therefore 
untrusted)  software  supported  by  a  TCB,  With 
modifications  as  needed  according  to  the  results  of  the 
software  analysis  discussed  earlier,  these  applications 
programs  can  be  used  to  perform  mari-machine  interface 
functions,  message  processing,  communications  suppoi'i , 
correlation,  graphics,  data  base  management,  and  other 
capabilities  as  needed.  The  use  of  a  single  untrusted 
DBMS  would  require  a  cryptographic  seal  to  protect 
resident  data  from  corruption,  while  multiple  single  level 
DBMSs  would  not.12,3) 

Developing  New  Applications 

In  May  1987,  a  large-scale  system  was  needed  within  the 
Department  of  Defense  to  support  resource  tracking  for 
planning,  programming  and  budgeting,  tactical  and 
strategic  wargaming  models;  manpower  models;  force 
structuring;  congressional  inquiries;  and  various  program 
administration  and  management  tasks.  The  existing 
system  consisted  of  a  B2  Top  Sceret/Socret  subsystem  and 
a  separate  Unclassified  subsystem.  The  replacement 
system  specified  an  initial  C2  hosL  environment  for  each 


processing  level  that  would  later  be  upgraded  into  a  B3/A1 
environment  by  use  of  trusted  communications  processors 
to  connect  the  hosts  in  accordance  with  Table  5  of  CSC- 
STD-004-85  [4],  The  initial  architecture  of  separate  C2 
"System  High”  mainframes  for  each  classification  level 
could  be  satisfied  by  using  a  C2  certified,  discretionary 
access  control  package  for  each  of  the  hosts. 

The  system  specification  required  a  single  communication 
interface  permitting  any  user,  under  mandatory  access 
rules,  access  from  any  terminal,  any  operating  system, 
and/or  any  data  base  at  any  of  the  three  classification 
levels,  subject  to  the  clearance  level  of  the  terminal  and 
user.  To  meet  this  requirement,  CDS  designed  a  Secure 
Communications  Processor  Environment  (SCPK)  based  on 
the  Gemini  Secure  Operating  System  (GEMSOS). 
GEMSOS  is  currently  under  evaluation  by  the  NCSC  and 
is  targeted  at  the  A1  level.  The  SCPE  consists  of  a  cluster 
of  Gemini  communications  processors  (using  GEMSOS) 
connecting  the  hosts  in  a  network  fashion.  The 
communications  processors  serve  as  Communications 
Control  Modules  (CCMs),  providing  direct 
communications  from  the  users  to  the  hosts.  One 
communication  processor  is  reserved  to  serve  as  the 
Access  Control  Module  (ACM),  providing  access  control 
and  audit  and  file  maintenance  functions.  Figure  2 
illustrates  this  architecture. 
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This  system  required  the  development  of  applications 
programs  to  perlorm  man-machine  interface  as  v/ell  as  to 
perform  CCM  and  ACM  functions.  The  first  step  was  to 
detail  the  requirements  of  the  applications  to  the  finest 
granularity  possible.  At  this  point,  we  were  faced  with  the 
same  question  concerning  trusted  code:  What  must  he 
trusted  and  what  can  be  untrusted?  While  our  software 
analysis  procedure  was  developed  for  use  with  existing 
software,  it  also  served  just  as  well  in  the  ease  of  designing 
new  software.  We  applied  the  procedure  to  each 
requirement  to  provide  insight  into  the  functions  that  are 
security  relevant.  Experience  with  both  old  and  new 
applications  demonstrated  that  the  same  minimization 
technique  applies  to  both  situations. 

Discussion 

During  system  analysis,  we  considered  several  questions. 
First,  how  to  determine  which  portions  of  the  software 


must  be  trusted?  We  began  by  separating  the 
requirements  into  security  related  and  non-security 
related  portions  as  a  base  for  analysis.  We  originally 
assumed  that  all  or  most  of  the  security  related  software 
would  need  to  be  trusted  because  of  the  security 
environment  of  the  system.  However,  as  the  requirements 
analysis  continued  and  as  we  analyzed  Instability  in  each 
case,  it  became  apparent  that  this  assumption  was  wrong. 
Only  the  security-related  software  which  does  not  conform 
to  the  model  must  be  trusted. 

Consider  the  case  of  an  incoming  message.  When  the 
message  first  enters  the  system,  it  must  be  labeled  with 
the  high  water  mark  of  the  incoming  communications  line 
because  all  data  within  the  system  must  be  labeled 
immediately  upon  entry.  As  the  header  is  parsed,  the 
classification  line  of  the  message  is  read  and  compared  to  a 
table.  When  the  correct  label  has  been  identified,  it 
replaces  the  initial  high  water  label.  At  first  glance,  it 
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appears  that  all  of  this  software  needs  to  be  trusted 
because  it  deals  with  security  data.  Further  analysis 
shows  that  this  is  not  true,  however.  The  classification 
line  parsing  function  can  be  reduced  into  three 
subfunctions:  reading  the  classification  line,  comparing  it 
to  a  table,  and  writing  the  new  label  to  the  record.  The 
first  two  subfunctions,  reading  the  classification  line  and 
comparing  it  to  a  tabic,  conform  to  the  Bell-Lapadula 
model  [5).  Since  these  subfunctions  conform  to  the  model, 
they  do  not  alter  the  secure  state  of  the  system  and 
therefore  do  not  need  to  he  trusted.  The  third  subfunction, 
writing  the  new  label,  does  not  conform  to  the  model 
because  in  most  cases  the  new  classification  label  is  lower 
than  the  old,  which  requires  a  write  down.  Since  the 
writing  subfunelion  does  not  conform  to  the  model,  it  must 
be  trusted. 

The  next  question  is  how  to  allow  the  remaining  untrusted 
applications  to  operate  in  a  multilevel  environment  and 
still  eliminate  the  usual  performance  problems  which 
plague  systems  of  this  type.  Performance  problems  are 
caused  by  the  necessary  TCB  mediation  of  all  accesses 
between  subjects  and  objects  in  the  untrusted  software. 
With  existing  applications,  the  accesses  between  subject 
and  object  are  so  numerous  that  performance  is 
significantly  degraded  while  the  TCH  performs  its 
required  management  activities.  The  solution  is  to 
minimize  TCH  mediation  as  much  as  possible  without 
sacrificing  the  security  integrity  of  the  system.  Our 
solution  is  to  limit  mediation  by  implementing  more 
complex,  larger  object  level  entities  (such  as  entire 
applications  processes  instead  of  modules).  We  accomplish 
this  hy  using  several  layers  of  each  untrusted  application, 
providing  one  layer  for  each  classification  level  of  data 
within  the  system.  For  example,  our  workstation  needs 
three  layers,  one  Top  Secret  with  compartments,  one  D.S. 
Secret,  and  one  Secret  Releasable.  These  larger  level 
objects  require  less  import  and  export  of  data  and 
therefore  less  TCH  mediation.  The  final  design  structure 
is  shown  in  Figure  15. 


Summary 

In  conclusion,  we  believe  that  the  analysis  procedure 
presented  provides  an  organized  approach  to  secure 
software  development  which  can  be  applied  to  existing 
applications  and  to  new  design  requirements.  In  this 
procedure,  the  system  processes  are  broken  down  into 
small  entities  that  pernjit  detailed  analysis  to  ensure  that 
the  trusted  processes  will  be  at  the  absolute  minimum. 
Wc  have  developed  two  conclusions  from  these 
experiences,  First,  the  processes  which  we  identified  as 
needing  to  be  trusted  were  those  which  violated  the 
security  model.  All  other  security  related  processus  are 
supplied  by  the  TCB.  Second,  performance  problems 
caused  lay  TCB  mediation  brought  about  by  security 
requirements  can  be  somewhat  alleviated  by 
implementing  larger  object  level  entities  in  a  layered 
fashion.  While  this  implementation  will  become  less 
efficient  with  larger  numbers  of  layers,  it  is  adequate  for 
many  existing  requirements  today. 
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